Skip to content

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant