IIUC, adding external packages is done by simply adding a URL to the app header, right? Something like this:
app [main] {
pf: platform "https://github.com/roc-lang/basic-cli/releases/download/0.10.0/vNe6s9hWzoTZtFmNkvEICPErI9ptji_ySjicO6CkucY.tar.br",
weaver: "https://github.com/smores56/weaver/releases/download/0.3.0/GJtHjepVuDUSzWogFflwMiqPnCV5FKR81722WVmUC5E.tar.br",
# ... other packages
}
A few related questions:
pip
or cargo
, to help find, install, update, and remove libraries? If not, is there any plan for that?Perhaps the answers to the above questions could be added to the tutorial or the FAQ?
Thanks for your help.
Is there a tool
Is there an official list of packages
nope
If not, any plan for that?
I think we may have docs with rough plans and overall it is definitely wanted, but nothing concrete to my knowledge
Should I fork basic-cli and somehow merge it with the Foo platform?
Forking basic cli and adding new libraries is recommended. Merging platforms isn't necessarily a thing, but you definitely could be a platform with all the effects of two other platforms.
The closest thing we have to a full list is Roc Awesome
I'm confused as to how Roc code can access non-Roc libraries in a flexible way.
It doesn't for the most part.
Part of the design for Roc is trying to enable platform authors to build elm like experiences. They are meant to be targeted to a specific audience. As such the author has to decide what to include and what to ban. Once that is decided, they only way to change it is to fork (or PR) the platform.
If platforms wanted to be composable, it would have to be done on the host language side. In rust, we could make a package that is the basis for many effects. I could be shared between basic-cli and basic-webserver and others for example.
Otherwise, a platform technically could allow for abitrary ffi via shared libraries and libffi. But that would be up to each individual platform to decide to do.
As an extra note, roc never plans to add a native escape hatch. The library ecosystem will remain 100% roc code. That said, it is allowed to generate effects. So a postgres library might require TCP primitives and would create tasks to interact with a postgres server.
So a lot of composibility for libraries in Roc will come from multiple platforms sharing a few basic primitives (like tcp or file io). Then the roc libraries will build more complex tasks off of the primitives.
Thanks for the clear answers. The design decision of having no escape hatch for Roc code is really interesting. I can see the benefits but I think it must go hand in hand with super easy composability at the platform level. E.g., suppose I want to use TensorFlow in a Roc project: I would fork basic-cli (or other platform) and do the work of wrapping TF's C++ API (plus CUDA). It's probably quite a lot of work to wrap TF, however, so I would probably share my basic-cli-with-tf platform on Github. But then someone else comes along and needs TF + A + B + C, and someone else needs TF + C + D + E, and someone else needs TF + A + E + F, and so on. If there's too much work involved in this kind of composition, I think it might be a blocker for many people. That said, I'm completely new to Roc, so perhaps I'll have a different perspective once I use it more.
Yeah, the combinatorial platform problem will definitely be interesting to see how it pans out in practice. My main thoughts today:
That said, things like TF will always be a hard problem. Using TF in rust is a hard problem and it has full ffi support. The tensorflow in rust library is 368,108
lines of code (hopefully essentially all autogenerated, but I didn't dig in).
Great answer, thanks Brian. The key will be in the tooling, the ecosystem, and the documentation. The various cases you listed should be as frictionless as possible. To be honest, this is such a fundamental design choice, I think it should be addressed upfront on the website, the pros and cons should be laid out clearly, the various scenarios you listed should be presented clearly, and the plan towards better platform composability should be laid out, or else newbies like me will be scratching their heads, since it's quite unusual for a general purpose language. To be fair, some parts of this are clearly stated on the website, but I for one didn't grasp the importance of it until now. WDYT ?
Happy to help btw
Yeah, I definitely think platforms could use more details on the website. Specifically something less focused on how they function and more focused on the implications for the ecosystem (including the goal to only allow pure packages but how we have tools to make those generate tasks nonetheless).
I think part of the core is mossing cause a lot of this is still being figure out with major changes to platforms to come. Also, major tolling improvements. All a long journey.
Last updated: Jul 06 2025 at 12:14 UTC