[airocker]

My point was that for every update, nixpkgs will have to be fixed if the build steps were changed. Currently, it is done by the actual software maintainers. Unless they all start building nixpkgs, it will be too much work to maintain.

[airocker]

The easy way to understand nix is : "A package manager that can compile all packages from source", this functional mumbo-jumbo is just confusing. If apt could compile all its packages from source with an option to do so and a cache, it would be as reproducible.

[pxc]

Debian packages are also built from source, but their model for building and distributing packages has a different ontology, it considers different kinds of resources than Nix does.

> If apt could compile all its packages from source with an option to do so and a cache, it would be as reproducible.

This is simply wrong. There are many source-based package managers besides Nix: Portage, Sorcery, Pkgsrc, Ravenports, MacPorts, FreeBSD Ports, etc. Some of them, like Homebrew for example, even support binary caching. None of them have the same kind of reproducibility guarantees as Nix offers, except for Guix.

The counterfactual about apt doesn't even really make sense, as using its own special source archive format, having binary repos, and performing install time dependency resolution based on version constraints are all pretty essential to what makes it apt. But even so, the mere fact that it installs to global, shared locations, e.g., under `/usr`, means that there are circumstances where you can't guarantee that a package will always load the same libraries it was built against, namely in the case of transitive dependencies which had different versions at build time.

[airocker]

I read a little more, you are right. There is definitely niceness but time will tell if all package maintainers will move to nix. IF they do, it will be great that dev mode and deploy mode can be all nix. Until then, not sure why I would use nix for developer workspaces.