Market nix not as a package manager but as a build tool and dependency management tool

@Ericson2314 I remember we were once joking the language should be called sleet because it has dynamic typing and feels squishy.

3 Likes

But wait, can you do a lot of complex and also deterministic configuration with Bazel? (I don’t know as I have never explored it. I’ve done builds with bazel, but not OS config)

As far as nix is concerned we are just “building something”. Take in some text files and spit some other files out. I don’t see why bazel couldn’t do the same.

1 Like

No you can’t, but so long as people don’t use Nix to do fine grained builds (and almost no people are trying to do this, sadly) Nix will be seen as a lousy tool for development.

2 Likes

I am using nix to do builds, but only at the granularity that “out of the box” nix supports :slight_smile:

Coming from the other end of the spectrum, where people don’t use anything but let’s say bash scripts or Make, nix is often a step up. They don’t have to rebuild every time if they are caching builds in CI, and they can build and try out many variations of dependencies. So it can be kind of a “gateway” toward bazel-like experience.

What needs to evolve in nix to get it all the way there? Implementing a content-addressed Nix ? Anything else? Are there existing builders that do what is needed that could be used by Nix for this purpose?

1 Like

I think in some respects the barriers really are more social/marketing/etc. We have a content-addrsssed Nix. We have the hydra patch (just need to turn it on). What we don’t have is people trying to use Nix this way (except for a few counter examples, not all open source), skipping stdenv.mkDerivation etc. And we don’t have the equivalent of Bazel’s “rules” repos — but that’s userland.

2 Likes

Sorry for not reading through all this. Just had a thought and wanted to throw it into the cauldron. That a term to describe Nix could be software composition framework.

Composing is kind of a superset of building. And it’s a framework because there’s a language, a store, a CLI, a daemon, etc…

3 Likes

I like the description, it explains it well; that said, I don’t think the meaning of that phrase would be clear to people reading it at first glace, which I think shouldn’t be the case with short descriptions like these. But that could just be me being blissfully unaware of the phrase too, feel free to disagree.

4 Likes

Yes, because no one knows what a software composition framework is, yet. That’s the challenge with entirely new ideas. The alternative approach is to go with an adjacent but well known term such as package manager, which “everyone knows” the meaning of. But Nix is more than that, I think. So whether it’s software composition framework or some other attempt at a somewhat accurate term, it will likely suffer the “yes, but what does that mean?” problem. I think we should accept that.

The Bazel and BuildStream communities had this discussion some 6 or 7 years ago and ultimately settled on “integration tool” or sometimes “build and integration tool” to make it clearer what an “integration tool” is for this reason (and to distinguish Bazel since it can legitimately claim to also be a “pure” build tool that doesn’t just call make or whatever).

This happened during a series of “build summits” where developers behind pants and some other cool integration-and-adjacent tools were present, too (and in fact, some folks from CERN who were contributing to nix at the time AIUI - who got me back into nix, in fact :wink: ).

Of course, as always, nobody took charge to update the language around this, especially cross-project, so to this date Bazel’s tagline hasn’t changed from “build system” and clearly the term “integration tool” has not entered people’s dictionaries.

My point is, I’m not sure that an effort to establish a new term, especially one that’s particularly wordy, is going to pan out :wink:

3 Likes