If you don't want a new package manager, why a new language? 10 февр. 2016 г. 0:40 пользователь <c...@corbinsimpson.com> написал:
> Hi! I've tried to start this discussion a couple times on IRC, but it > hasn't really gotten attention, so: > > I'm one of the developers of Monte, a new programming language. We don't > want to write a package manager, because package managers are hard. (Also > we've been watching npm happen for the past few years.) So we plan to use > Nix. However, we've got some requirements for our package layout, and we > haven't seen anybody else do all of the things we want at once. Here's > what we're thinking: > > * Monte packages shouldn't live in nixpkgs. We use standalone Nix > expressions to build stuff like our runtime, and it makes development very > speedy since we do not have to round-trip our Nix changes through nixpkgs. > We also want to keep Nix expressions for packages close to the packages > themselves (see next point.) Perhaps when our ecosystem has developed > more, we can revisit this. > > * Monte packages should bundle their own Nix expressions. Our reasoning is: > > ** Suppose that we have some "mtpkgs" tree, which is like nixpkgs but only > contains a Nix expression for building some or all of the Monte runtime > and packages. However, now we've decoupled the description of the packages > from the packages themselves, which makes maintaining the package harder, > since changes to the package require a corresponding change to mtpkgs. We > didn't gain anything over just using nixpkgs! > > ** Okay, so instead we make a JSON (or whatever) description of each > package, and ship that with the package. Then, we interpret that > description as a Nix expression, and do Nix things as usual. Except that > this doesn't work, because now the JSON description is a new package > manager format! We didn't want that. > > ** So it seems like packages should ship with a Nix expression. > > * Packages should be easy to cargo-cult. This might sound weird, but my > experience in other ecosystems (especially Python and Perl) has taught me > that most package descriptions are cargo-culted from other similar > packages. We should have a very custom Nix derivation-producing function > which turns a minimal Nix expression into a full Monte package > description. > > So with that in mind, here's where we currently are. We have a runtime and > some packages. There's a terrible terrible Nix function that generates > derivations ( > https://github.com/monte-language/typhon/blob/master/default.nix#L11-L34 > ). An example usage is ( > https://github.com/monte-language/mt-rational/blob/master/default.nix ). > > As you can see, our derivations are not especially good. We don't have a > good way to locate a runtime so that we can call ``montePackage`` easily. > Once our packages start depending on other Monte packages, the problem > will only be worse. We also have this indirect dependency on nixpkgs for > library stuff, which is worse than a direct dependency or no dependency at > all. > > We're seeking any advice on how to make this situation better. As far as > we can tell, nobody else has tried to make Nix their first-class preferred > package management solution for their language, so we are blazing trails > here. > > Thanks! > ~ C. > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
