Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Enable config.strictDepsByDefault = true by default #178468

Open
trofi opened this issue Jun 21, 2022 · 12 comments
Open

Enable config.strictDepsByDefault = true by default #178468

trofi opened this issue Jun 21, 2022 · 12 comments
Labels
0.kind: bug 6.topic: cross-compilation Building packages on a different sort platform than than they will be run on 6.topic: stdenv Standard environment

Comments

@trofi
Copy link
Contributor

trofi commented Jun 21, 2022 •
edited

strictDeps helps keeping cleaner PATHs 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 precise depsBuildBuild & co. finer grained equivalents.

nixpkgs/pkgs/stdenv/generic/make-derivation.nix

Lines 127 to 128 in cd88f86

, # TODO(@Ericson2314): Make always true and remove
strictDeps ? if config.strictDepsByDefault then true else stdenv.hostPlatform != stdenv.buildPlatform

@trofi
Copy link
Contributor Author

trofi commented Jun 21, 2022 •
edited by Artturin

Piling on the packages known to break with config.strictDepsByDefault = true:

@trofi trofi mentioned this issue Jun 21, 2022
Merged
13 tasks
@veprbl veprbl added 6.topic: stdenv Standard environment 6.topic: cross-compilation Building packages on a different sort platform than than they will be run on labels Jun 22, 2022
@erdnaxe
Copy link
Contributor

erdnaxe commented Oct 7, 2022 •
edited

libxml2 seems to break with config.strictDepsByDefault = true. Adding python in nativeBuildInputs fixes the issue.
I am not really confident to propose this as a patch as I don't understand why this exists: pythonSupport ? enableShared && stdenv.buildPlatform == stdenv.hostPlatform (in pkgs/development/libraries/libxml2/default.nix).

@Artturin
Copy link
Member

Artturin commented Oct 7, 2022

libxml2 seems to break with config.strictDepsByDefault = true. Adding python in nativeBuildInputs fixes the issue. I am not really confident to propose this as a patch as I don't understand why this exists: pythonSupport ? enableShared && stdenv.buildPlatform == stdenv.hostPlatform (in pkgs/development/libraries/libxml2/default.nix).

python is probably being disabled because cross-compilation enables strictDeps and so breaks the python detection

i'll fix it

@erdnaxe
Copy link
Contributor

erdnaxe commented Oct 7, 2022 •
edited

There seems to be a similar issue to libxml2 with libxslt.

I am building a aarch64-linux NixOS system from master using config.strictDepsByDefault = true. I will update the following list with the files in which I had to add strictDeps = false; to get a working system:

@Artturin
Copy link
Member

Artturin commented Oct 7, 2022 •
edited

libxml2, libxslt, optionsJSON: #194941

@Artturin
Copy link
Member

perlPackages.{Po4a,AlienLibxml2},kmod,liblouis #218503

This was referenced Mar 3, 2023
Merged
Merged
Merged
Merged
@kirillrdy kirillrdy mentioned this issue Mar 13, 2023
Merged
12 tasks
@erdnaxe erdnaxe mentioned this issue Mar 29, 2023
Merged
12 tasks
@erdnaxe erdnaxe mentioned this issue Apr 11, 2023
Open
@erdnaxe erdnaxe mentioned this issue Oct 31, 2023
Merged
13 tasks
@roberth roberth mentioned this issue Jan 8, 2024
Closed
@AndersonTorres
Copy link
Member

Ward because I need to learn this.

This was referenced Jan 13, 2024
Merged
Merged
Merged
Merged
Merged
Merged
Merged
@infinisil
Copy link
Member

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.

@trofi
Copy link
Contributor Author

trofi commented Jan 15, 2024

What are third parties exactly? Are (for example) users of .override, .overrideAttrs and overlays = [] considered to be third-parties? I wonder if nixpkgs even provides a way to distinguish internal from external users.

I had an impression that external users are expected to pin to a particular revision of nixpkgs to get a reasonable build result. Otherwise users have to constantly adapt to internal changes like gcc updates, parameter additions and removals, package removal/deprecation and .nix file moves. Largest breakages are usually covered by release notes.

@infinisil
Copy link
Member

infinisil commented Jan 15, 2024 •
edited

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 import <nixpkgs> {} value instead of going through overlays should be considered third-party code. And it's possible to implement code that can distinguish that (it'll have to touch the core of Nixpkgs though).

Notably this would also be useful for a number of other improvements to stdenv.mkDerivation that would be backwards-incompatible, but can happen in Nixpkgs.

I had an impression that external users are expected to pin to a particular revision of nixpkgs to get a reasonable build result. Otherwise users have to constantly adapt to internal changes like gcc updates, parameter additions and removals, package removal/deprecation and .nix file moves. Largest breakages are usually covered by release notes.

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.

@AndersonTorres
Copy link
Member

Is extra-cmake-modules affected by strictDeps = true?

@eclairevoyant eclairevoyant mentioned this issue Jan 22, 2024
Closed
benley pushed a commit that referenced this issue Jan 22, 2024
@AndersonTorres
melonDS: 0.9.5 -> 0.9.5-unstable-2024-01-17 (#282620)
522c89c 
* 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
@paparodeo
Copy link
Contributor

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.

@erdnaxe erdnaxe mentioned this issue Jun 23, 2024
Merged
13 tasks
@Pandapip1 Pandapip1 mentioned this issue Jul 6, 2024
Closed
13 tasks
@SomeoneSerge SomeoneSerge mentioned this issue Jul 24, 2024
Merged
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
0.kind: bug 6.topic: cross-compilation Building packages on a different sort platform than than they will be run on 6.topic: stdenv Standard environment
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@trofi @veprbl @erdnaxe @AndersonTorres @infinisil @Artturin @paparodeo