Dear Joyriders: https://github.com/BetterThanTomorrow/joyride/releases/tag/v0.0.43 • Add uuid constructor to sci Thanks @djblue! 🙏
I'm very close to getting a release for Portal to run on Joyride! My initial approach ended up going in a direction I didn't want to support. My current approach is updating the runtime code to support joyride's sci implementation. Then during Portal's vscode initialization, calling Joyride's runCode on all the runtime source. This will work for Portal since it already has an extension that can leverage the Joyride api, but has there been any conversations on how Joyride users should "officially" pull in dependencies?
You are close to what? 🤯
We have talked about how to pull dependencies. Or rather that it would be very nice. Nothing that amounts to a discussion, though. Sounds like it is time to start discussing!
https://github.com/djblue/portal/pull/204/files#diff-45c303b5cdcf37d30658873462f94c78f7d0043415e62499c59a37191e2c2a16R175-R187is my current approach for getting the portal runtime loaded into joyride 👌
A current issue is that the Portal extension has to wait for when the Joyride extension is up before it can eval the runtime source. This presents two issues. Users can't opt-out of setup since it is eager and if Joyride has just been installed during the current session, the Portal runtime setup will have already missed the window for running. Do you have any ides for how to better provide the Portal runtime source to Joyride users?
In my initial approach, I tried to expose the portal api directly via " which is how I suspect Joyride intended users to interact with other installed extensions. However, that presented an issue since Portal needs access to knowledge of the various Clojure data types which is why I went the pure source route.
Ideally, when Joyride goes to resolve source code for namespace, it could ask around to see if others know where to find it 👌