Change all packages from "name" to "pname"+"version", remove all uses of meta.version and meta.tag #103997
Open
6 of 7 tasks
Labels
3.skill: sprintable
5. scope: tracking
Long-lived issue tracking long-term fixes or multiple sub-problems
Comments
nh2
added a commit
to nh2/nixpkgs
that referenced
this issue
Nov 16, 2020
Github is where upstream's development happens now, and building from repo makes adding patches and overriding the commit easier. Also use pname+version, see NixOS#103997.
nh2
added a commit
to nh2/nixpkgs
that referenced
this issue
Nov 16, 2020
Github is where upstream's development happens now, and building from repo makes adding patches and overriding the commit easier. Also use pname+version, see NixOS#103997.
nh2
added a commit
to nh2/nixpkgs
that referenced
this issue
Nov 16, 2020
Github is where upstream's development happens now, and building from repo makes adding patches and overriding the commit easier. Also use pname+version, see NixOS#103997.
10 tasks
|
I can do it too :) |
Raw Markdown for a list of affected packages
Automatically generated by |
|
This list might contain some errors, since I used a fairly naive regex to make it. I already marked three items for which @nh2 filed a PR. |
|
@kisik21 please try to collapse the comment with |
|
I grepped for package explicitly that explicitly set Is this just about making Its a common pattern for packages to e.g. bind pname + version with a Would be nice if recursive sets had a kind of edit: I guess one can just pass |
|
@siraben done, but the markdown is not processed inside of HTML as per Markdown spec, so I wrapped it in |
|
I just checked for some packages that I maintain, such as pname = "miranda";
version = "2.066"; |
|
@kisik21 the markdown works for me if I simply remove the
|
@siraben Yes, correct. |
@xaverdh This is just about making the technical change to use
This pattern still counts as the old (bad) pattern, for the new (good) pattern one has to give
I don't thinks so, or at least I haven't seen that done. I believe the most common pattern to re-use versions e.g. in |
|
@nh2 done, the markdown indeed works. Weird, it didn't work the first time! |
|
I tried a search with the following command. Turned up quite a lot of results. This list packages that have a version number in their name. $ ag "[^p]name.*=.*-[0-9]+.*;" pkgs/ -G default.nix | grep -v patch > report.txt
$ wc -l report.txt
1622 report.txt |
|
Any ideas on how to automate this process? Take name = "pngcrush-1.8.13";
src = fetchurl {
url = "mirror://sourceforge/pmt/${name}-nolib.tar.xz";
sha256 = "0l43c59d6v9l0g07z3q3ywhb8xb3vz74llv3mna0izk9bj6aqkiv";
};Seems like we would need some more complex meta-programming to be able to do this change en masse. |
10 tasks
|
A few comments:
|
|
Maybe we should coordinate this with 21.03 release then? |
I can't remember if there's some thing with repology only using |
@edolstra I don't understand, 13000 packages already use Are we talking about something else? Or do you mean that we don't gain additional features yet? |
"Migrating" here has the sense of a full migration. In the sense of parsing etc. the Nix language doesn't care much about it - it's just cosmetical. |
Yes, and it doesn't actually do anything since Nix doesn't know about those attributes. For instance, |
This change is not neccessarily just about |
Repology just uses |
|
What happened to https://github.com/NixOS/nix/blob/master/src/libexpr/names.cc ? Where is the parser now? |
|
https://github.com/NixOS/nix/blob/HEAD@%7B2019-09-11T15:42:25Z%7D/src/libexpr/names.cc#L19 → https://github.com/NixOS/nix/blob/ae3191666f1828d9694fb615a721d409fb8582bd/src/libstore/names.cc#L19 Refined GitHub extension allows you to view comment link targets at the time they were linked. |
This was referenced Oct 1, 2022
Fonts are mostly just files which get downloaded and copied to the nix store. We don't need to layer an extra derivation which copies $src into a directory into $out. |
|
As a note all these PRs are making the fonts dependent on the compilers since it's using A true solution IMO would be having fetchers support pname & version or just leaving them alone, rather than using |
If this is the case, shouldn't we remove being able to pass |
|
No because I disagree with that statement. If you're just fetching data and maybe moving or deleting some files there is no benefit IMO for using in mkDerivation. |
|
I agree. What I meant is that if that statement was the general consensus, then that would have to happen, which it hasn't. Which leaves us at a crossroads. It seems that the move to mkDerivation for fonts happened without much discussion, so let's have that discussion now, reach a consensus, and make the required changes (potentially reverting the mkDerivation migrations). |
|
Is there any advantage in using a pure For me |
We are only using one fixed output derivation instead of two where the second just copies files around. Every derivation has a small overhead which we can save here. Also it makes it easier to rebuild FODs to see if the extra script they are using still works. |
Don't you mean one FOD and one non-FOD, in the case of using mkDerivation? |
|
Yes, one FOD and one not FOD. |
|
Now we can continue, I think :) |
dbueno
added a commit
to dbueno/dotfiles
that referenced
this issue
Oct 13, 2022
instead of just name. there is an effort underway to change this everywhere in nixpkgs (NixOS/nixpkgs#103997) and code for vim plugins seems to depend on the new behavior
13 tasks
teto
pushed a commit
that referenced
this issue
Oct 25, 2022
13 tasks
|
I have a question about "environments" they ususally tend to not have any version. what should happen to pkgs/misc/my-env/default.nix ? what about patches? |
12 tasks
|
I think they are not to be versioned at all. |
12 tasks
12 tasks
9 tasks
samueldr
added
the
5. scope: tracking
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
It seems like there isn't a tracking issue about this long-term effort yet (e.g. to mention in commit messages and to make it sprintable).
Nixpkgs moved to an explicit versioning scheme, with the plan to change all packages like so:
See the sprint checkbox list for the remaining packages: #103997 (comment)
This obviates
meta.versionandmeta.tag; they should be removed (as discussed in #12156).Tangentially related: Where to put
unstableversions / package names (see #68518).Details on what's right and what isn't
Note that the following pattern is not good because it still uses
name:In the new approach,
pnameandversionhave to be given directly tomkDerivation.You can use
mkDerivation recto be able to re-use e.g.versioninsrcor other fields:Automation
You can link big treewide efforts/PRs here (tick merged ones):
Tasks
meta.tagshould indeed be removed as wellupdate-walker.shscript? Ask @7c6f434c: meta.updateWalker: remove because it is not used #151363updateWalkerbecause it's the last reference toupdate-walker.sh: meta.updateWalker: remove because it is not used #151363The text was updated successfully, but these errors were encountered: