Ian McLerran (Apr 29 2024 at 19:50): Ian McLerran (Apr 29 2024 at 19:50):I remember a previous discussion where there was mention of a desire to allow Roc packages (and platforms) to import other packages for their own use, such that common resources have a single source of truth. IE: The basic-cli and basic-webserver platforms might both want to use Utc, and a date/time package might also want to use Utc. Just wondering if plans for such a feature have developed any farther?
Ian McLerran (Apr 29 2024 at 19:54):I bring this up because I have realized that My Roc-IsoDate package will not be able to provide Utc as a parsed type. This is because Utc is an opaque type. If an app imports Utc from the platform, it cannot also import Utc from a package, since they will conflict, and since the type is opaque, if a function cannot simply return Utc and have have the app treat it like a Utc without importing the type from the package, like it could if the type were non-opaque.
Ian McLerran (Apr 29 2024 at 19:57):This means that my package cannot provide the functionality to parse directly to Utc. It can convert to nanos since the epoch which can then be converted into Utc by fromNanosSinceEpoch (not the end of the world, and what I will end up doing), but it means my intention for a unified API will be slightly less unified.
However this has reminded me how much I wish there were someway for packages and platforms to import other packages into their own code bases, and wondering if there are any plans around this.
Richard Feldman (Apr 29 2024 at 20:30):yeah the current situation is because of a bug in how imports are implemented - but @Agus Zubiaga has fixed it in a branch that hasn't quite been merged yet! That will let platforms depend on packages, and packages depend on other packages
Ian McLerran (Apr 29 2024 at 21:16):Awesome! Great to hear thats coming along! Thanks for the hard work @Agus Zubiaga! :octopus:
Last updated: Jul 26 2025 at 12:14 UTC