You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If multiple versions of a package are required, the convention is to introduce additional top-level attributes reflecting the alternation in their name, such as python2, ffmpeg-full, firefox-esr, haskellPackages.aeson_1_5_6_0. This is problematic because the attributes are not discoverable, follow no shared convention and they make overrides more problematic. Additionally there is a desire to be able to refer to specific versions of packages
Goal
When there is a consistent way to access specific versions in nixpkgs
The text was updated successfully, but these errors were encountered:
Two package-set version key approaches I used were: pkgs.someScope.foo.v1_0_1 ( "group-by" ) and pkgs."someScope/foo/1.0.01" ( "pkg-keys" ) were two patterns I had used. pkg-keys were easier to mapAttrs over; but in a REPL having to quote sucks.
In both cases I made aliases pkgs.foo an alias of a marked "default" ( usually latest ) of the fully qualified name.
For aliasing the "group-by" form was sort of problematic ( I kept botching overlays because of the multiple sub-scopes ).
There is both the version attribute and the attribute name to consider.
In Nixpkgs Python packages set the guideline is that attributes names have to be lowercase and can have dashes. To indicate a variant an underscore should be used between the original attribute name and the variant suffix. Note this isn't used throughout yet.
Issue description
If multiple versions of a package are required, the convention is to introduce additional top-level attributes reflecting the alternation in their name, such as
python2
,ffmpeg-full
,firefox-esr
,haskellPackages.aeson_1_5_6_0
. This is problematic because the attributes are not discoverable, follow no shared convention and they make overrides more problematic. Additionally there is a desire to be able to refer to specific versions of packagesGoal
When there is a consistent way to access specific versions in nixpkgs
The text was updated successfully, but these errors were encountered: