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.

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

lib/strings: guard against an easy mistake #44928

Merged
merged 1 commit into from Nov 11, 2020

Conversation

vcunat
Copy link
Member

@vcunat vcunat commented Aug 12, 2018

This would catch the bad fwknop flags fixed in 580cab5, during evaluation already.

This would catch the bad `fwknop` flags fixed in 580cab5,
during evaluation already.
@LnL7
Copy link
Member

LnL7 commented Aug 12, 2018

Why do we have these helper functions? They don't provide any meaningful abstraction over literal strings IMHO.

@vcunat
Copy link
Member Author

vcunat commented Aug 12, 2018

They don't really, but writing these ifs everywhere would seem cumbersome, if you want to pass the negative flags as well.

@dezgeg
Copy link
Contributor

dezgeg commented Aug 12, 2018

According to documentation, the standard autoconf macros --disable-foo and --without-bar are defined as equivalent to --enable-foo=no and --with-bar=no.

So stdenv.lib.withFeatureAs wgetSupport "wget" "${wget}/bin/wget" can become --with-wget=${if wgetSupport then "${wget}/bin/wget" else "no"}. Which has better grep-ability and (at least to me) less cognitional load. I'd get rid of these miniscule helpers.

@vcunat
Copy link
Member Author

vcunat commented Aug 12, 2018

Yes, sounds nice. It won't be possible to guard against the typo like this PR does :-) but that's a relatively small thing and without the function the typo may be harder to make.

@edolstra
Copy link
Member

I'm not really in favor of these. I once had to spend a day reverting the previous attempt at such functions (https://github.com/NixOS/nixpkgs/commits/e3356b396d308264ab04cb3e997edc048af2fea2). The problem was that people starting exposing every configure flag as Nix function arguments...

@mmahut
Copy link
Member

mmahut commented Aug 3, 2019

Any updates on this pull request?

@stale
Copy link

stale bot commented Jun 1, 2020

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 stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 1, 2020
@siraben
Copy link
Member

siraben commented Nov 11, 2020

Any updates on this pull request?

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Nov 11, 2020
@edolstra edolstra merged commit f9dd8f0 into NixOS:master Nov 11, 2020
@siraben
Copy link
Member

siraben commented Nov 11, 2020

I'm not really in favor of these. [..] The problem was that people starting exposing every configure flag as Nix function arguments...

@edolstra What's the rationale for merging it? Did something change in the last 2 years?

EDIT: Change just seems to be about asserting isString feat, I see.

@vcunat vcunat deleted the p/configure-assert branch December 30, 2020 14:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants