andrewchambers / hpkgs

A package repository for hermes
45 stars 3 forks source link

Plans for language package managers? #82

Open akavel opened 4 years ago

akavel commented 4 years ago

A lot of language ecosystems nowadays have their own package managers, e.g. Janet->jpm, Go->go get, (Lua->LuaRocks), JS->npm, Rust->cargo, Nim->nimble, etc. etc. In some cases they're more of an optional helpful addition, like in case of LuaRocks IIUC; but in other cases like with Go, they seem ingrained deep enough that I find it hard to imagine to not use them. Do you have some plans/ideas you could share w.r.t. how to handle this merry company in hpkgs? I'm asking especially based on the fact that in nixpkgs the situation is IMO super messy and chaotic (as a lot of other things), due to their evolutionary & "prime mover" position. Hpkgs has the benefit of hindsight, and IIUC you have enough experience with NixOS that I would suspect you probably have some ideas/opinions how to maybe try and aproach this systematically & in some unified way? I skimmed through a few packages already in hpkgs but didn't seem to notice anything in this area yet.

andrewchambers commented 4 years ago

I have some experience with pip, go, jpm and cargo.

My current plans are as follows:

Brain dump:

If necessary I may trick some of these tools into thinking they are downloading from urls, while actually serving them fixed tarballs via a fake http proxy.

If the tool is not cooperative and doesn't have a notion of a globally installed library (like cargo), I may abandon the idea of sharing libraries between packages. I have no plan to implement something like carnix, even though other people can try if they wish.

I may consider splitting languages into their own repositories that are free to depend on hpkgs core.

In general, Hermes prefers to make a toolbox of small functions to do common operations, rather than make a framework to do everything.

akavel commented 4 years ago

I think https://github.com/andrewchambers/jpm-to-hermes showcases the general idea nicely - I guess thanks to Janet being a general purpose language, those converters/proxies can potentially all be written in Janet (?), and also I didn't realize again how relative paths seem to make things simpler. Cool & thanks for the reply! :)

andrewchambers commented 4 years ago

those converters/proxies can potentially all be written in Janet

To me it makes sense the tool is either in Janet, or in the language the tool is targeting. Anything else just seems like a burden.