Kiryl Dziamura (Jun 25 2025 at 07:57): Kiryl Dziamura (Jun 25 2025 at 07:57):is there a document on package management and modules in general? I want to clarify a couple of things:
app,module,package,platform,hosted - so many types of modules are enlisted in the docs. is this separation inevitable? is it possible to optimize it somehow? Luke Boswell (Jun 25 2025 at 08:21):(1) -- you can only import packages (a platform is a special kind of package and there must be exactly one) in the app header using URL. Modules are imported using import Foo.Bar exposing [thing] where Bar.roc is located at the directory /Foo/Bar.roc
(2) you can have multiple versions of the same package (except platforms) and alias them to help migration.
(3) I'm not sure... as in the package imports another package. That is ok (though not implemented yet in either rust or zig compiler)
(4) I think it works nicely to separate these things as they have different requirements/use cases. Note hosted wont be required in future.
(5) I'm not sure
Anton (Jun 25 2025 at 08:23):(5) I think you can modify a roc file in your cache and that will work, like this file for example:
/home/username/.cache/roc/packages/github.com/lukewilliamboswell/roc-json/releases/download/0.13.0/RqendgZw5e1RsQa3kFhgtnMP8efWoqGRsAvubx4-zus/StringFormat.roc
I thought of a package overloading system where roc can automatically copy the package contents to the app folder and resolve package from there
Anton (Jun 25 2025 at 08:38):(if it decides to fetch them again for some reason)
I'm not 100% sure but I don't think it will.
Anton (Jun 25 2025 at 08:38):I thought of a package overloading system where roc can automatically copy the package contents to the app folder and resolve package from there
How would this be triggered?
Anton (Jun 25 2025 at 08:39):I remember in python you could just go to source for e.g. a package in the IDE and modify it right there, that worked well
Kiryl Dziamura (Jun 25 2025 at 08:47):How would this be triggered?
there's smth similar here: https://pnpm.io/cli/patch
though it's not very ergonomic in my opinion
it may be roc patch <full url to the package> which fetches the package to .patches/<package> and then compiler resolves imports from there.
after the modifications, you can either add them to index, or (e.g.) run roc patch shrink that creates a .patches/<package>.diff you can also add to the index.
it's a real world problem of a bug somewhere deep in dependencies. sometimes you need to just make it work not waiting for a new release (and a release of depended package)
Kiryl Dziamura (Jun 25 2025 at 08:48):basically, vendoring
Anton (Jun 25 2025 at 08:49):it's a real world problem of a bug somewhere deep in dependencies. sometimes you need to just make it work not waiting for a new release (and a release of depended package)
Yeah, agreed!
Anton (Jun 25 2025 at 08:50):it may be
roc patch <full url to the package>which fetches the package to.patches/<package>and then compiler resolves imports from there.
That seems reasonable, I personally would not put it in a hidden folder but that's a detail. Can you make a post in #ideas ?
Richard Feldman (Jun 25 2025 at 11:31):yeah I actually have thought about some sort of roc vendor command
Kiryl Dziamura (Jun 25 2025 at 11:33):
Last updated: Jul 26 2025 at 12:14 UTC