-
Notifications
You must be signed in to change notification settings - Fork 1
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
base: master
Are you sure you want to change the base?
Conversation
If we changed
this feels much more intuitive than:
Since package toggles get lumped with version info, now there's a separation of concerns between dependencies and build time flags |
Hmm
doesn't really work if people do:
because the downstream usage of openssl is more opinionated |
## Future work | ||
|
||
- Mitigate argument passing awkwardness with mkAutoCalledGenericDir proposal (TBD). | ||
- Provide updater-script for use with generic packages |
There was a problem hiding this comment.
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.
Another consideration, is "retaining" the previous variant information. So things like |
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 aopenssl.v3.X
which can be selected.Rendered: https://github.com/jonringer/eeps/blob/many-variants/eeps/0005-many-variants.md