-
-
Notifications
You must be signed in to change notification settings - Fork 13.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable config.strictDepsByDefault = true
by default
#178468
Comments
Piling on the packages known to break with
|
libxml2 seems to break with |
python is probably being disabled because cross-compilation enables strictDeps and so breaks the python detection i'll fix it |
There seems to be a similar issue to libxml2 with libxslt. I am building a aarch64-linux NixOS system from master using
|
libxml2, libxslt, optionsJSON: #194941 |
perlPackages.{Po4a,AlienLibxml2},kmod,liblouis #218503 |
Ward because I need to learn this. |
Since nobody mentioned this before, we should only do this for Nixpkgs, not third-parties, at least not without a proper warning first. Otherwise we break package builds for thousands of users. |
What are third parties exactly? Are (for example) users of I had an impression that external users are expected to pin to a particular revision of |
Overlays make this a bit tricky because it's how Nixpkgs defines its packages internally, but third-parties can also provide overlays. So I think it's fine to treat overlays as Nixpkgs code. But other than that, anything using the resulting Notably this would also be useful for a number of other improvements to
While we don't yet have a clear guideline on API stability guarantees, my take on it is that we should guarantee stability for the code that we control. This includes all the Nix code in Nixpkgs, including e.g. the passthru attributes of packages. We are responsible for that code and should take care to not break it. But this doesn't include the contents of the packages: If upstream of a package happens to break for all users, we aren't responsible for that, it's upstream that should get the complaints. We can still include a note on that in the release notes as a courtesy, but it's not required. |
Is extra-cmake-modules affected by |
* melonDS: refactor - extra dependency: zstd - finalAttrs design pattern - get rid of nested with - add AndersonTorres as maintainer * melonDS: set strictDeps as true - Why does it not find extra-cmake-modules in nativeBuildInputs? Let's mark it on issue #178468 * melonDS: 0.9.5 -> 0.9.5-unstable-2024-01-17
note that cmake effectively puts buildInputs in the search path and before PATH when strictDeps is true and should probably get fixed before strictDeps becomes the default. one attempt to fix this is here #318226 but it is still a WIP. |
strictDeps
helps keeping cleanerPATH
s for cross-compiled packages. But it's also useful to have for native builds: it helps writing nix derivations that have better chance of working when cross-compiled later.A bunch of packages will need to sort out their
buildInputs / nativeBuildInputs
depends. Or more precisedepsBuildBuild & co.
finer grained equivalents.nixpkgs/pkgs/stdenv/generic/make-derivation.nix
Lines 127 to 128 in cd88f86
The text was updated successfully, but these errors were encountered: