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

stdenv/mkDerivation: derive pname and version when not given #124520

Closed

Conversation

Synthetica9
Copy link
Member

Motivation for this change

Add pname and version to all packages automatically when not already given.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • 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 nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Added a release notes entry if the change is major or breaking
  • Fits CONTRIBUTING.md.

@github-actions github-actions bot added the 6.topic: stdenv Standard environment label May 26, 2021
@Synthetica9 Synthetica9 force-pushed the mkderviation-auto-pname-version branch from 823e796 to 07667b9 Compare May 26, 2021 17:16
@Synthetica9 Synthetica9 force-pushed the mkderviation-auto-pname-version branch from 07667b9 to ab64e0c Compare May 26, 2021 17:17
@Synthetica9
Copy link
Member Author

This shouldn't break anything, unless anyone is explicitly depending on pname or version not being set somewhere. Is it major enough for a release notes entry? Do we want to backport this to 21.05?

@grahamc
Copy link
Member

grahamc commented May 26, 2021

I am keen on seeing the evaluation performance report in the Checks tab for this change.

@jtojnar
Copy link
Member

jtojnar commented May 26, 2021

It sounds problematic for the same reason as #68620 (comment).

@Synthetica9
Copy link
Member Author

It sounds problematic for the same reason as #68620 (comment).

Yeah, I was thinking about adding a check to ensure that name = "${pname}-${version}

Synthetica9 added a commit to Synthetica9/nixpkgs-upkeep that referenced this pull request May 27, 2021
Plexamp doesn't have a version attribute because the builder we use doesn't support that. Until NixOS/nixpkgs#124520 is merged, we have to use a bit of a workaround.
@xaverdh
Copy link
Contributor

xaverdh commented May 28, 2021

actually this is pretty cool!

Yeah, I was thinking about adding a check to ensure that name = "${pname}-${version}

we could also hunt down those occurrences (in nixpkgs), by adding a trace

@stale
Copy link

stale bot commented Jan 9, 2022

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

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jan 9, 2022
@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 6, 2023
@drupol
Copy link
Contributor

drupol commented Jun 6, 2023

Hi @Synthetica9,

I'm cherry-picking abandoned PR in nixpkgs and I found this one, I think this could be a nice addition.

Do you think you could give it a refresh so we can move forward?

If not, feel free to close the PR.

Thanks in advance.

@jtojnar
Copy link
Member

jtojnar commented Jun 6, 2023

Another reason this can be problematic is that with the current convention for unstable versions, it can split it improperly – not that there are many such packages (16 according to comm -12 <(rg -l '\bname.+\$\{version' | sort) <(rg -l 'version = .+unstable' | sort)).

But I would rather just treat name as opaque and require explicit pname and version for project packages.

@Artturin
Copy link
Member

Artturin commented Jun 20, 2023

We're moving away from setting name #103997 so i don't see a need for this PR

@Artturin Artturin closed this Jun 20, 2023
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

6 participants