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

Meta refactor #22277

Closed
wants to merge 1 commit into from
Closed

Meta refactor #22277

wants to merge 1 commit into from

Conversation

vcunat
Copy link
Member

@vcunat vcunat commented Jan 29, 2017

Motivation for this change

I was slightly taken aback by the fact that nix-env -qa does not check dependencies of packages, but I was unable to fix that without a significant performance hit, so I left it as it was.

I tested this fixes #21845, #22102, #7541, hopefully without any caveats.

@mention-bot
Copy link

@vcunat, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @Profpatsch and @wmertens to be potential reviewers.

@Ericson2314
Copy link
Member

Yes please! As a bonus, pkgs/stdenv/generic/default.nix is actually readable now, thank god!

in if !v.valid
then throwEvalHelp (removeAttrs v ["valid"])
else true;
pos' =
Copy link
Member

Choose a reason for hiding this comment

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

While we're at it, can we make this just the default arg for pos, rather than using , pos ? null and if pos != null?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sounds good; pushed.

in

lib.addPassthru
(derivation
Copy link
Member

Choose a reason for hiding this comment

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

Is the indentation right here? I think derivation is taking two arguments but they are indented at different levels.

Copy link
Member Author

Choose a reason for hiding this comment

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

No, the other argument is for addPassthru, and derivation takes a single argument only.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, hah. This seems so obvious in hindsight.

@edolstra
Copy link
Member

Does this mean that nix-env -qa will now show disallowed/broken packages? The intent was that they don't show up.

Moving meta checking into a separate file is a good idea, though I'm not sure if it should be added to lib (since lib is more for generic functions rather than specific functions used in only one place).

@vcunat
Copy link
Member Author

vcunat commented Jan 30, 2017

@edolstra: I left this as it was/is now, i.e. disallowed/broken packages are hidden but other packages that depend on such are shown. Fixing that would be easy and I had it so originally, but there would be a large performance price for that query.

I used lib, as I originally thought it would be used by buildEnv and perhaps others as well, but later I realized that they use stdenv, too... so currently I know no other place that would utilize the functions. If you like, we can move the file to pkgs/stdenv/generic/check-meta.nix or similar and not expose the functions.

@Profpatsch
Copy link
Member

I’m not sure if this preserves semantics.

Did you move the assert?

@vcunat
Copy link
Member Author

vcunat commented Jan 30, 2017

@Profpatsch: I don't get which assert exactly you mean, but the whole checking code was moved into a separate file.

@Profpatsch
Copy link
Member

@vcunat the one directly before mkDerivation in the old version.

@vcunat
Copy link
Member Author

vcunat commented Jan 31, 2017

@Profpatsch: if it's supposed to be this one

# Throw an error if trying to evaluate an non-valid derivation

that's now done inside addMetaCheckInner... and it's delayed to evaluating the name. (Your old PR did this when evaluating the builder, but that one's not evaluated at all during nix-env -qa by default.)

@vcunat
Copy link
Member Author

vcunat commented Feb 4, 2017

I suppose I'll have to look at the performance again. For nix-env -qa it seemed OK but eval-release shows a significant performance hit:

$ time nix-instantiate --eval --strict --show-trace ./maintainers/scripts/eval-release.nix > /dev/null
36.16user 0.71system 0:24.42elapsed 150%CPU (0avgtext+0avgdata 2578940maxresident)k
$ time nix-instantiate --eval --strict --show-trace ./maintainers/scripts/eval-release.nix > /dev/null
46.40user 0.89system 0:32.41elapsed 145%CPU (0avgtext+0avgdata 3273876maxresident)k

(taken from the tarball job; similar to Hydra's evaluation)

@Ericson2314
Copy link
Member

Ericson2314 commented Feb 16, 2017

Anything this is waiting on? I'm eager to it merged!

@vcunat
Copy link
Member Author

vcunat commented Feb 16, 2017

I haven't got to looking into the nontrivial performance regression. There have been more pressing matters, even in nixpkgs.

@Ericson2314
Copy link
Member

@vcunat Any time to look at this again? I think I'll need it for cross compilation soonish.

else if !allowBroken && meta.platforms or null != null && !lib.lists.elem system meta.platforms then
{ valid = false; reason = "broken"; errormsg = "is not supported on ‘${system}’"; }
else { valid = true; };
# ^ checkMetaValidity
Copy link
Member

Choose a reason for hiding this comment

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

This comment probably isn't needed now this isn't in a huge scary file :).

Copy link
Contributor

Choose a reason for hiding this comment

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

When does null != null?

Copy link
Member

Choose a reason for hiding this comment

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

You have the precedence wrong, perhaps? Read it as (meta.platforms or null) != null. It's a shorter way of doing meta ? platforms && meta.platforms != null

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, the or operator binds even closer than function application. NixOS/nix#629

Copy link
Member Author

Choose a reason for hiding this comment

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

In any case, this discussion thread is on a stale diff. Current PR is: #27045

@vcunat
Copy link
Member Author

vcunat commented Jun 26, 2017

@Ericson2314: I've been no good on nix* time in the past months an most of it was taken just by trying to fixup channels. Still, I can't predict this well.

You're interested in the laziness part? (d2e4af7 ATM) I don't yet know how exactly is cross-compilation evaluated now, even :-)

vcunat referenced this pull request Jun 26, 2017
The invalid meta.outputsToInstall has been blocking channel updates.
https://mailman.science.uu.nl/pipermail/nix-dev/2017-June/023991.html
@Ericson2314
Copy link
Member

@vcunat I suppose the laziness is useful too, but mainly I want it because stdenv.generic is big and scary and this makes it less so :). I had some vague thoughts too about separating stdenv from mkDerivation, and this tidyness would make thinking about that easier.

@vcunat
Copy link
Member Author

vcunat commented Jun 28, 2017

Right, that no-lazy part is easy to do and I found no performance impact, so I think I can do that before this week ends.

@Ericson2314
Copy link
Member

Wonderful, thanks!

@Ericson2314
Copy link
Member

@vcunat I really shouldn't be looking a gift horse in the mouth :), but when you do this, if you could use http://github.com/obsidiansystems/nixpkgs/tree/ericson2314-nixpkgs-base as your base branch, that would be much appreciated. That branch is my last merged PR to nixpkgs, so it always points to an upstream commit. That way, if master is broken, I know PR starts from a known-good change which includes all my cross changes on top. Then I can I can continue working from your PR tip rather than the merge commit and all will be well.

Alternatively, I'd be happy to pick up this PR if you are too busy---I think I should be able to figure out how to do the split without the laziness change. Certainly keeping the channels in a good state is important and tiresome work so you deserve a break!

@vcunat
Copy link
Member Author

vcunat commented Jun 28, 2017

OK, shouldn't be a problem, as I see it's not too late behind master.

@0xABAB
Copy link
Contributor

0xABAB commented Jun 28, 2017

I think querying such information requires a database. One design is to let Nix become a database engine. Another (my idea) is to treat Nix as a data source and load that data into something which is already a database engine (don't really care which one) and then query that. Building the database index is an operation that should be done in the background.

Can someone tell me why my idea would be a bad idea?

@vcunat
Copy link
Member Author

vcunat commented Jun 29, 2017

More like a DB that caches the evaluations done by nix. Many would appreciate that, apparently, and DBs seem common in packaging systems. Still, I don't think it's really related to this PR.

@vcunat
Copy link
Member Author

vcunat commented Jul 2, 2017

First stage now on #27045.

Allow querying meta on disallowed derivations – broken, unfree, etc.
But keep checking of the conditions including dependencies when
instantiating a derviation.

Performance: this causes creating another copy of the attr-map.
`nix-env -f . -qa` shows a roughly 2% increase in time and space.
`nix-instantiate --eval --strict --show-trace ./maintainers/scripts/eval-release.nix`
shows a higher increase (8-9%), but *real time* is not noticeably different,
probably due to GC being parallelized.
@vcunat
Copy link
Member Author

vcunat commented Jan 14, 2018

To be clear, meta and most other attributes can now (67e8392) be queried on disallowed derivations.

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.

Allow platform compatibility to be queried on packages
7 participants