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

[0005] Standardize how packages expose many variants #5

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jonringer
Copy link
Contributor

@jonringer jonringer commented Oct 25, 2024

Standardize how packages which many versions or variants are constructed and exposed.

Also reduces the number of "variant aliases" needs to be defined in a scope. E.g. openssl_3_0, openssl_3_1, openssl_3_2, openssl_3_3; now there's just a openssl.v3.X which can be selected.

Rendered: https://github.com/jonringer/eeps/blob/many-variants/eeps/0005-many-variants.md

@jonringer
Copy link
Contributor Author

If we changed .override to .overrideDeps, and changed .overrideVariant to .overridePackage, we could live in a world where you could do:

patchedCurl = let 
  newerCurl = prev.curl.overridePackage {
    version = "4.9.1";
    srcHash = "...";
    withDocs = false;
  };
  in newerCurl.overrideDeps {
    openssl = openssl.v3_2;
  };

this feels much more intuitive than:

  patchedCurl = let
    newerCurl = prev.curl.overrideAttrs (oldAttrs: {
      version = "4.9.1"
      src = fetchurl {
        url = "https:// ....";
        hash = "...";
      };
      # patches may also need to be touched
    };
    in newerCurl.override {
      openssl = openssl_3_2;
      withDocs = false;
    };

Since package toggles get lumped with version info, now there's a separation of concerns between dependencies and build time flags

@jonringer
Copy link
Contributor Author

Hmm

  in newerCurl.overrideDeps {
    openssl = openssl.v3_2;
  };

doesn't really work if people do:

{
  openssl,
  ...
}:
... {
  buildInputs = [ openssl.v3_1 ];
}:

because the downstream usage of openssl is more opinionated

@jonringer jonringer changed the title Initial many variant Standardize how packages expose many variants Oct 26, 2024
@jonringer jonringer changed the title Standardize how packages expose many variants [0005] Standardize how packages expose many variants Oct 26, 2024
## Future work

- Mitigate argument passing awkwardness with mkAutoCalledGenericDir proposal (TBD).
- Provide updater-script for use with generic packages
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Been thinking about this, could create a variantsUpdateScript which consumes the information from versions.nix, as part of mkPassthruAttrs, we can add a passthru.variantAttr, so the update script know which variant is being targeted. Still need to filter out things like .full variants, as they aren't really updated so much as they are buildtime descriptions.

@jonringer
Copy link
Contributor Author

Another consideration, is "retaining" the previous variant information. So things like ffmpeg.full.v8 would retain the "I want to do a full build, but with major version 8"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant