4 ms·
The thing that you and sibling miss is that this only applies to the one direct dependency on a package, but not on dependencies required by that package. For t
by infogulch 4y ago
The thing that you and sibling miss is that this only applies to the one direct dependency on a package, but not on dependencies required by that package. For that you have to work with any build and dependency resolution system that the package or its author uses, and you're up a creek without a paddle if the author doesn't care to help you debug your own system.
- viraptor 4y agoI'm not missing this. It's not a problem the way you describe it. With nix you generally choose between packaging with deps that are in the repo, or effectively provide your own list of vendored versions. Both cover all the deeper dependencies and you get the choice of integrating with the project's build system or ignoring it and providing your own lockfile equivalent. (the latter especially if the build does something really weird) Even if authors are not responsive, nix maintainers provide the required patches or disable the broken functionality. So no, things are mostly ok.
- SuperSandro2000 4y ago> that this only applies to the one direct dependency on a package, but not on dependencies required by that package Right now in nixpkgs we manage all dependencies in all packages front to back. So all dependencies of a dependency and dependencies of dependency dependencies and so on.