Add nix package type
#314
Add nix package type
#314
Conversation
This adds a first version of the Nix package type. Signed-off-by: Raito Bezarius <[email protected]>
| pkg:nix/[email protected]?drvpath=/nix/store/3nxf8kw3vgghz2y72b9qwi01sz62nhyk-glibc-2.39-52.drv&output=out&repository=github:user/nixpkgs | ||
| pkg:nix/[email protected]?drvpath=/nix/store/r34i4md1cmc19392zbbp9ya5nmd0av0k-systemd-255.6.drv&output=dev | ||
|
|
||
|
|
There was a problem hiding this comment.
You probably want to remove "nix" from the old list below.
| nix | ||
| --- | ||
|
|
||
| ``nix`` for Nix derivations: |
There was a problem hiding this comment.
| ``nix`` for Nix derivations: | |
| ``nix`` for Nix store paths: |
The PURL is for each store path, and we may have multiple PURL for different output paths in the same derivation.
| ``nix`` for Nix derivations: | ||
|
|
||
| - The default package repository is <https://github.com/NixOS/nixpkgs> but the ``repository`` qualifier can override the package repository. | ||
| - The ``name`` is the package ``pname`` field of the given derivation. It is case sensitive. |
There was a problem hiding this comment.
We don't always have the pname / version separate. Deep down pname and version are concatenated into a single string. Should something creating a PURL try to split this off? (Probably fine, but in that case, see the comment on the version field).
There was a problem hiding this comment.
the current state of name, pname, and versioning standards was part of why I didn't expect there to be a PURL standard yet for nix. (TBH I haven't checked on the current-state of discussions for a while so maybe it's settled lol)
Although it'd be great if this spec discussion helps push things forwards
|
|
||
| - The default package repository is <https://github.com/NixOS/nixpkgs> but the ``repository`` qualifier can override the package repository. | ||
| - The ``name`` is the package ``pname`` field of the given derivation. It is case sensitive. | ||
| - The ``version`` is the ``version`` field of the given derivation. |
There was a problem hiding this comment.
How do PURL look like for store paths where the version cannot be extracted? Is this field (and other fields) optional or required? The spec for other PURLs in this file do explicitly say what's required and what not.
| - The default package repository is <https://github.com/NixOS/nixpkgs> but the ``repository`` qualifier can override the package repository. | ||
| - The ``name`` is the package ``pname`` field of the given derivation. It is case sensitive. | ||
| - The ``version`` is the ``version`` field of the given derivation. | ||
| - The ``drvpath`` qualifier is the derivation path (``.drvPath``). |
There was a problem hiding this comment.
Do we want to have an outpath here too, or are PURL always for individual output paths, so this information would be redundant?
Is drvpath optional or required?
| - The ``name`` is the package ``pname`` field of the given derivation. It is case sensitive. | ||
| - The ``version`` is the ``version`` field of the given derivation. | ||
| - The ``drvpath`` qualifier is the derivation path (``.drvPath``). | ||
| - The ``output`` qualifier is the output field, by default: ``out`` |
There was a problem hiding this comment.
| - The ``output`` qualifier is the output field, by default: ``out`` | |
| - The ``output`` qualifier is the name of the output, which helps to distinguish in the case of multi-output derivations |
The "default" behavior is confusing. It doesn't describe if it should always be set, or if it is "out" in case the field is not present.
Or should it always be set to something, and the fact it's "out" in single-output derivations is an implementation detail of Nix that should be left out of the spec? I prefer this one, which is my the suggestion uses this variant.
I don't think it should be omitted in case of single-output derivations, it'd be odd if it suddenly would appear if an expression is refactored to multiple outputs.
There was a problem hiding this comment.
including the output field also accounts for if the default is changed in the future and shouldn't be very painful to just include
There was a problem hiding this comment.
we should just map this to outputName of the drv. Then this works with lib.getLib etc
|
|
||
| ``nix`` for Nix derivations: | ||
|
|
||
| - The default package repository is <https://github.com/NixOS/nixpkgs> but the ``repository`` qualifier can override the package repository. |
There was a problem hiding this comment.
Does this field even matter at all? With just the PURL we cannot reproduce the drv path anyways, there's a lot of other details (like rev, system, ...) we'd need. Also, the line gets blurry if you have a repo that imports nixpkgs, but overrides an expression, what should this be set to?
Inclined to remove this, this can only be a hint at most.
There was a problem hiding this comment.
With this field being mostly informative I feel we'd want a nar package type or at least a nar field to better identify where you got the package from if using a cache like cache.nixos.org. ommitted or something for if you built it locally?
There was a problem hiding this comment.
It is not identifying the package. If you have a nar sha256 hash, you can fetch it from any content-addressed store.
There was a problem hiding this comment.
"what" being covered by the hash, but "where" can also useful for some governance.
Also if you can find that hash in your content-addressed store then great, but if you can't you might at least want a possible alternative location to check to find the same artifact described by the PURL.
Also lightning quick response! ⚡
| - The ``name`` is the package ``pname`` field of the given derivation. It is case sensitive. | ||
| - The ``version`` is the ``version`` field of the given derivation. | ||
| - The ``drvpath`` qualifier is the derivation path (``.drvPath``). | ||
| - The ``output`` qualifier is the output field, by default: ``out`` |
There was a problem hiding this comment.
including the output field also accounts for if the default is changed in the future and shouldn't be very painful to just include
|
|
||
| ``nix`` for Nix derivations: | ||
|
|
||
| - The default package repository is <https://github.com/NixOS/nixpkgs> but the ``repository`` qualifier can override the package repository. |
There was a problem hiding this comment.
With this field being mostly informative I feel we'd want a nar package type or at least a nar field to better identify where you got the package from if using a cache like cache.nixos.org. ommitted or something for if you built it locally?
| ``nix`` for Nix derivations: | ||
|
|
||
| - The default package repository is <https://github.com/NixOS/nixpkgs> but the ``repository`` qualifier can override the package repository. | ||
| - The ``name`` is the package ``pname`` field of the given derivation. It is case sensitive. |
There was a problem hiding this comment.
the current state of name, pname, and versioning standards was part of why I didn't expect there to be a PURL standard yet for nix. (TBH I haven't checked on the current-state of discussions for a while so maybe it's settled lol)
Although it'd be great if this spec discussion helps push things forwards
|
see #149 |
jkowalleck
added
PURL type definition
This adds a first version of the Nix package type.