-
-
Notifications
You must be signed in to change notification settings - Fork 13.5k
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
Legacy stdenv.mkDerivation
#295044
Comments
Big project. Can add a bunch of context.
It seems that a more minimal "stdenv", say A minimal alternative to stdenv would satisfy the needs for minimal shell derivations as well.
Mentioned this in structuredAttrs PR: to solve not just the stringification (goal of structuredAttrs) but tackle as well the design problem that unrecognized attrs are turned into environment variables.
User interface can be simplified:
Also there's a divide between sources+patches and sources+filters. CA-derivations blurs the line between eval-time source filtering and build-time source filtering, though we'll want to keep source filtering in order not to be strict in huge subdirectories that are ignored. Ideally we'll unify these concepts. Source filtering itself should be improved as well
Referring to the input roles required for cross compilation? Solving "Derivation attributes are stringified and turned into environment variables" somewhat reduces this as well.
RFC92 fundamentally decouples package-ness from derivation-ness: only the first derivation exists at eval time, whereas the outputs come from the produces derivation.
Defining "package" (as an attrset that goes beyond the derivation itself) |
Brief overview of issues I encounter with |
Module style composition would be nice. The module system we have is a bit too complicated and possibly a little slow for the purpose of packaging. A module system with only the features we need would be simpler; for example: https://gist.github.com/roberth/940dff88ca5f5f95949dc309dbe60a65 |
A possible example module. I use Autoconf style Adding https://github.com/aameen-tulip/at-node-nix/blob/main/pkgs/build-support/setup-hooks/pjs-util.sh |
As an aside, guix handles the second point really nicely. The store derivations are generated by scheme, and the builders are scheme interpreters (rather than bash in the nixpkgs case). The attributes are just s-expressions, so they can be passed to and handled by the builders naturally. |
A modular Setting a "well-known" mkDerivation argument to its empty and default value should have no effect on the derivation hash. |
Just to clarify, do you mean "it does not change the hash with existing
implementations", or "after we close this issue we will ensure that
empty/default args will no longer change the hash"?
…On Thu, Nov 17, 2022, 9:33 AM Robert Hensing ***@***.***> wrote:
A modular mkDerivation would only provide the defaults it needs, but
provide them nonetheless, making it a potentially simpler and more
efficient solution for the problem to be solved in NixOS/nixpkgs#201131
<#201131> which can be summarized by
the requirement:
Setting a mkDerivation argument to its empty and default value should have
no effect on the derivation hash.
—
Reply to this email directly, view it on GitHub
<https://github.com/nixpkgs-architecture/issues/issues/3#issuecomment-1318812550>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA3ORYR2QQHMCH4PIUM6RBTWIZF5RANCNFSM535TQOKA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
This is not the case yet, as it depends on the fate of #201131
I would say yes, but I don't think this issue is well categorized, as a modular |
Though it's more of an implementation detail, I'll link this comment of mine since it's related to that problem: #204303 (comment) |
The lack of package-local variables came up again here when supporting overlay-style Whatever we use to construct packages should have a namespace where generic code can put or look for information that doesn't automatically end up in the build sandbox and affecting hashes. |
Issue description
The current base builder of nixpkgs is
stdenv.mkDerivation
, which has some weird legacy features:Goal
This issue is done when a better and more consistent
stdenv.mkDerivation
exists and is used as the base for all builders.Project Board
The text was updated successfully, but these errors were encountered: