stdenv: Deprecate string configureFlags

[Ericson2314]

Motivation for this change

This is better style, especially once we use the Nix 2.0 feature to go directly to bash arrays. #44423 already made nixpkgs largely conforming.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Fits CONTRIBUTING.md.

---

[GrahamcOfBorg]

Success on x86_64-linux (full log)

Attempted: stdenv

Partial log (click to expand)

/nix/store/i6vl5lwlz5jbkg4r6p340dwmj6fha3xq-stdenv-linux

[GrahamcOfBorg]

Success on aarch64-linux (full log)

Attempted: stdenv

Partial log (click to expand)

/nix/store/pjq5v1xgljr4ygb1h1xfybdjydczcqiw-stdenv-linux

[Ericson2314]

Qt 3 part moved to #45888

[GrahamcOfBorg]

Success on x86_64-darwin (full log)

Attempted: stdenv

Partial log (click to expand)

/nix/store/95bw3cdcgc8c0rrvqwvhvc805pdv7rmx-stdenv-darwin

[timokau]

Doesn't the title suggest the exact opposite? If we deprecate non-string configureFlags, all configureFlags would be strings.

[dezgeg]

especially once we use the Nix 2.0 feature to go directly to bash arrays

Yes, when we get to use the feature this will make sense. But currently we do not, and as the code for using it doesn't exist, it obviously won't make it to 18.09.

And if/when we do it, it doesn't make sense to single out just configureFlags, there are other cases like makeFlags that should be switched out in the same go.

So as such, the situation as in @edolstra's comment seems to still hold: #15799 (comment)

[LnL7]

Yes, when we get to use the feature this will make sense. But currently we do not, and as the code for using it doesn't exist, it obviously won't make it to 18.09.

Isn't something like this necessary as a first step to get nixpkgs ready for structured builder attributes?

[edolstra]

I'm not sure null should be disallowed, since it has a special meaning because of the __ignoreNulls feature in Nix. For example, you can add an attribute like

configureFlags = if stdenv.isDarwin then ["blabla"] else null;

and this won't change the derivation on non-Darwin platforms (so doesn't cause a rebuild).

[Ericson2314]

@edolstra Currently because of the way configurePlatforms is handled, it's already a list anyways, so there is no risk of mass rebuilds.

In general, I rather default everything to [], false, etc (or conversely filter out everything that isn't needed) so that the no-rebuild trick happens automatically without needing to write awkward things at the package level.

[dezgeg]

Isn't something like this necessary as a first step to get nixpkgs ready for structured builder attributes?

Well, for one we first need a transition plan for not silently breaking code which has list elements
with spaces (i.e. things like [ "--foo 123" "--bar 456" ]) and assume the current behaviour.

[Ericson2314]

@dezgeg We can additionally deprecate spaces unless the Nix 2.0 thing is in use. (I recall being able to use it on a derivation-by-derivation basis.)

If someone tells me how to do that structured attractive check, I'll add it and fix the title (should be "non-list"), and then I think this is ready to go.

[LnL7]

@dezgeg Ah, good point that set of packages is probably much bigger.

[GrahamcOfBorg]

Success on x86_64-linux (full log)

Attempted: stdenv

Partial log (click to expand)

/nix/store/i6vl5lwlz5jbkg4r6p340dwmj6fha3xq-stdenv-linux

[GrahamcOfBorg]

Success on aarch64-linux (full log)

Attempted: stdenv

Partial log (click to expand)

/nix/store/pjq5v1xgljr4ygb1h1xfybdjydczcqiw-stdenv-linux

[GrahamcOfBorg]

Success on x86_64-darwin (full log)

Attempted: stdenv

Partial log (click to expand)

/nix/store/95bw3cdcgc8c0rrvqwvhvc805pdv7rmx-stdenv-darwin

[vcunat]

I don't feel like putting such a thing into 18.09 this late (especially when a consensus isn't really clear yet). I don't see a problem with postponing this, with master branch (perhaps) getting stricter than stable.

[edolstra]

There's not really an advantage to doing this now rather than if/when we ever switch to structured attributes.

[Ericson2314]

@edolstra if we wait until when we actually make the transition, then there's no time to deprecate. The whole point of depreciations is to clear the way for breaking changes that happen later; they must happen in advance to provide any benefit.

[Ericson2314]

@vcunat certainly we should have concensus before doing anything, but I don't think "last-minute" depreciations are bad in and of themselves in that they are purely cautionary: there's no corresponding last minute action the user is forced to take.

The slight downside with a post-release deprecation is we effectively wait another cycle before doing anything. I.e people that only use stable wouldn't see it until 19.03, and I think we all agree that the minimum warning time before some breaking change should be counted for them, not the unstable users that get the head start.

[Ekleog]

(triage) Given there is certainly a need for consensus here, I think this should be made into a proper RFC.

[stale]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

[stale]

I marked this as stale due to inactivity. → More info

[Artturin]

Let's do this after 22.05 branch off so we do this at some point instead of procrastinating until we have to do this

there's been about 8 releases since 2018 so..