jan kili (Feb 25 2022 at 17:53): jan kili (Feb 25 2022 at 17:53):This is worth knowing about, and it might even save us time in developing Roc's package manager: https://blog.replit.com/upm
jan kili (Feb 25 2022 at 17:53):Now that we’ve aggregated all of the language-specific code into a single place, we hope it will be much easier to add package management support for new languages, like Emacs Lisp. Check out UPM on GitHub and see what it would take to add your favorite package manager to Repl.it! (Or, if Repl.it doesn’t have your favorite programming language yet, check out our other open-source projects, Polygott and Prybar, to help us add it.)
jan kili (Feb 25 2022 at 17:56):Eh, nvm, this project might be dead: https://github.com/replit/upm/graphs/contributors
Zyansheep (Jun 07 2022 at 14:27):UPM might not be a good idea, but what about integration with the Nix package manager?
Anton (Jun 07 2022 at 15:19):Interesting suggestion, I know we planned on using github for hosting packages but nix might be a better fit and it could save us from having to implement more stuff ourselves. This seems worth looking into sometime @Richard Feldman.
Richard Feldman (Jun 07 2022 at 15:34):oh I have a bunch of thoughts on this topic, but short version is that the idea involves intentionally not coupling to any particular other package management system :big_smile:
Zyansheep (Jun 07 2022 at 15:38):What ideas do you have for a package manager?
Richard Feldman (Jun 07 2022 at 15:42):I need to write them all down somewhere, but one of the main ideas is to have the package index be decoupled from hosting the source code itself.
So if I go to publish a package, I need to host the code somewhere. (In practice this will probably be GitHub releases 99% of the time because it's so easy to automate publishing that way with a GitHub Action, but it doesn't have to be GitHub - any URL will do - in case someday GitHub falls out of favor, or for people who prefer to host elsewhere.)
Richard Feldman (Jun 07 2022 at 15:43):when you publish, the index looks at the url you provided and takes a hash of the sources, so that we can verify that even though you're downloading the package sources from an arbitrary URL, we know the contents are the same as what was originally published
Richard Feldman (Jun 07 2022 at 15:44):we can also do a backup somewhere in case someone "unpublishes" someday by deleting their package's URL - we can restore it behind the scenes from the backup (e.g. to a forked GitHub release) and update the index to point to the new URL
Richard Feldman (Jun 07 2022 at 15:47):so this means we have a centralized index that you can install things from, we can enforce semver like Elm does, and we aren't coupled to GitHub, but we also don't have the npm problem of "bandwidth costs have gotten so high that we need VC funding to survive, and then eventually get acquired by Microsoft"
Richard Feldman (Jun 07 2022 at 15:48):the downside is that publishing is higher friction than it is with elm packages because there's the extra step of having to get your sources onto a URL, but I think GitHub Actions can make that a very minor inconvenience
Richard Feldman (Jun 07 2022 at 15:51):I also have separate ideas about identity and authentication and package namespaces, but I'm at the airport, so that will have to wait :big_smile:
Zyansheep (Jun 08 2022 at 00:07):Ooh, I like those ideas. if there was a viable, fast alternative to centralized hosting (IPFS is to slow) I would totally just say to use that but without decentralized storage, having the option of being able to store the source wherever is nice. The only concern I would have is that if someone develops a library but uses slow hosting for their source releases, that might be a problem. Maybe a community-mirror system could be used like how arch linux does it?
Last updated: Jun 16 2026 at 16:19 UTC