> I think the idea is exciting but difficult. Some notes / questions: > > 1/ Nix stores its data in /nix/store - is your package manager OK with > root > access? There are ways around that, e.g. using --with-store-dir but see > [1].
*Nix* is our ideal package manager. We don't have any other package manager. We are not retrofitting some ecosystem to Nix; we hope to build our ecosystem on Nix. We currently use standard Nix tools to manipulate our environments. I have an IRC bot written in Monte; its deployment looks like: $ nix-channel --update # Fetch the latest builds from our Hydra $ nix-env -i airbrus # Update the bot to the newest version $ airbrus ... # Run the bot! Our current foray is mostly focused around how to set up development environments using Nix, and what kinds of files and conventions define a Monte package. > 2/ Do you want semver versioning or some form of always-follow-HEAD with > stabilization branches like e.g. nixos or stackage LTS do? We haven't decided. Semver's "nice". I've used it in the Haskell ecosystem. It works as long as everybody plays nice. Also Haskell's linkage restrictions ("Cabal hell") mean that while semver might be *correct* semantically, it's also a pain to manage. Both Allen and I are long-time Twisted folk, and Twisted uses semver but its major number always reflects the current Gregorian calendar year. This enables us to see at a glance how old a system is when people come asking for help. "Help, my server doesn't work and I'm using Twisted 8" instantly tells us that they're on an eight-year-old library version. This is technically incorrect semver since the API doesn't break anually, but nobody minds. Go's YOLO non-versioning is interesting. Gophers, like Haskellers, typically only care about whether their program compiles and superficially appears to work. We could take this a step further in Monte, since we have builtin testing facilities, and allow the "latest" version of a package to be added to an environment as long as it passes all of its unit tests. We are sheepish about this path because it requires everybody in the ecosystem to write good tests, and (let's be honest here) nearly nobody writes enough tests. An idea from Haskell that we recently floated was the idea of the "Monte Platform": Just like the Haskell Platform, we bless a certain set of libraries at a certain version. This doesn't solve every problem, but definitely being able to incant $(nix-env -i monte-platform) could improve our new-user story. > 3/ Will you ever bind to c libraries like postgresql? We don't intend to produce any Monte runtime which provides a C FFI. I'm sure that somebody will do it eventually, but it probably won't have our blessing. Of course, if you have a hypothetical Monte Web application, and you want to use Pg as your database, then your Nix expression for your application might include a Pg dependency, but that's different. > If you can fall back on binaries from your underlying system then maybe 1 > isn't a problem - at the cost of reproducibility. > > Personally I think I'd follow Domen's advice of machine readable metadata > and convert those into one big nix-expression on the fly before running > e.g. nix-build. > There are already several good examples for packaging *all* libraries for > an ecosystem from metadata (Peter's excellent Haskell work, Gleb's hex > packages, ...). To reiterate an earlier point: There's nothing preventing us from using nixpkgs and putting all of our Monte package descriptions into nixpkgs. It's just not desirable; Monte package authors shouldn't have to wait for nixpkgs PRs when they are publishing new Monte packages. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev