[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nix-dev
Subject:    Re: [nix-devel] Resolving the conflict between allowBroken and platform-based feature selection
From:       Shea Levy <shea () shealevy ! com>
Date:       2018-03-30 11:05:48
Message-ID: 87lge9su0j.fsf () xps13 ! shealevy ! com
[Download RAW message or body]


Hi Eelco,

Eelco Dolstra <eelco.dolstra@logicblox.com> writes:

> Hi,
> 
> On 03/29/2018 03:01 PM, Shea Levy wrote:
> 
> > I recently introduced [1] lib.meta.enableIfAvailable, which allows
> > marking a build input as only being used for a build if it is
> > "available", e.g. Nix only depending on libseccomp if building for
> > Linux. This lets us keep logic about when a particular input makes sense
> > local to the input instead of spreading it to every package that depends
> > on it as we do now
> 
> That was already the case in your example [1], because kexectools was set to
> null on unsupported platforms.

Yes, but switching to the meta-attribute based approach allows us to
distinguish at the *usage* site whether a given dependency is optional
or not. It also makes errors more explicit if you reference the
derivation directly rather than through buildInputs (i.e. a message
about broken platforms rather than a message about getting some
attribute of null) and can move us to the point where we don't have to
explicitly filter out nulls when processing buildInputs.

> Using a meta attribute seems worse, because it
> requires evaluating a derivation, which is 1) slower; 2) might fail (e.g. if
> there is an assertion like isLinux somewhere).
> 
> Once we have something like
> https://gist.github.com/edolstra/29ce9d8ea399b703a7023073b0dbc00d#packages (i.e.
> where you don't need to evaluate a derivation to get the meta-data of a
> package), these problems would go away though.
> 

I'm in favor of something like that broadly, but I don't think we need
to go nearly that far to make this approach generally applicable. With
the way meta.platforms and meta.broken work nowadays, it seems like the
top-level asserts aren't really necessary anymore. Is an evaluation
through corepkgs/derivation.nix that doesn't force any of the
derivationStrict bits really that bad? If it's really bad, we could have
something like callPackageOn platforms.linux ../pkgs/development/libfoo,
which can be orthogonal to the null vs meta.available question and be as
fast as you like.

In any case, we don't need to remove asserts everywhere for this to
work. We just need the meta attribute of the package we're specifically
trying to see is available to be evaluable on all platforms, which is a
much more localized question.

> 
> > Unfortunately, "available" as currently used is a very overloaded
> > term. A package's availability is a function both of package-specific
> > features *and* a user's settings.
> 
> This is always the case. You can always have overlays that change packages in
> arbitrary ways.
> 

Sure, but I think there's a difference between overlays, which are quite
clearly meant to change packages in arbitrary ways, and a setting which
in intent is just meant to let *more* things build, not build differently.

> 
> > This means package behavior can vary
> > from machine to machine despite building for the same systems. In some
> > cases, this may be desirable: If I don't set allowUnfree and a package I
> > ask for optionally depends on some package with unfree license, maybe
> > the right behavior is to just get the variant of the package without the
> > unfree dependency rather than an error. In other cases, this is
> > definitely the wrong behavior: If I set allowBroken, that doesn't mean I
> > want Nix to depend on libseccomp on Darwin!
> 
> I guess the use of "broken" is wrong in this case. libseccomp is not "broken" on
> Darwin, as that would imply it might be fixed at some point (or might already
> work but the maintainer just hasn't noticed yet). Instead it should be marked as
> unavailable in a way unaffected by allowBroken.
> 

Yeah, I think Michael Raskin is right that we probably want
tristate-like behavior here. It doesn't address the allowUnfree
question, but that one seems less problematic.

> 
> -- 
> Eelco Dolstra | Infor / LogicBlox | http://nixos.org/~eelco/
> 
> -- 
> You received this message because you are subscribed to the Google Groups \
> "nix-devel" group. To unsubscribe from this group and stop receiving emails from \
> it, send an email to nix-devel+unsubscribe@googlegroups.com. To post to this group, \
> send email to nix-devel@googlegroups.com. To view this discussion on the web visit \
> https://groups.google.com/d/msgid/nix-devel/5b97ea9d-5d7b-1e40-04b3-5f144bd2e4c6%40logicblox.com.
>  For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "nix-devel" \
group. To unsubscribe from this group and stop receiving emails from it, send an \
email to nix-devel+unsubscribe@googlegroups.com. To post to this group, send email to \
nix-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/nix-devel/87lge9su0j.fsf%40xps13.shealevy.com. For \
more options, visit https://groups.google.com/d/optout.


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]