[Nix-dev] Underspecified 'disabled' attributes in python-packages.nix

[Domen Kožar]

>
>  >     in job ‘python33Packages.almir.x86_64-linux’:
>  >     Package ‘python3.3-Beaker-1.6.4’ in
>  >
>  ‘/nix/store/vr71jj15vk57p0mb85annpszswhhf7f4-git-export/pkgs/development/python-modules/generic/default.nix:57’
>  >     is marked as broken, refusing to evaluate.
>  >
>  > The error you are seeing is because you changed the 'disabled'
>  > attribute to behave as the package is broken in [79a5fec9].
>
> actually, no, that is not true.
>
> I changed the "disabled" attribute to set "meta.broken" instead of
> throwing an error, because Hydra knows about meta.broken and does not
> emit an error for packages that have this attribute set. All the errors
> you currently see in [1] were there long before my change, and in fact
> the plethora of evaluation errors from Python packages was what
> motivated that change in the first place!
>

Let's first define what the problem is with current implementation:

- "broken" or "disabled" package is not propagated to reverse dependencies.
If a package A depends on package B and B is marked as broken/disabled,
package A will still be evaluate-able and will result in an evaluation error

- evaluation errors spams the hydra error tab page

I've opened https://github.com/NixOS/nixpkgs/issues/6561 to address the
issue and agree how we can fix it.

Currently meta.broken is filtered out by `release-lib.nix` code, but we
shouldn't tag those packages as broken
if they are really just not supported.



>  > I'm reverting [79a5fec9] and sequential commits as they don't improve
>  > the situation,
>
> The commit *does* improve the situation because it removed a few hundred
> evaluation errors from the Hydra error page. If you revert it, then
> those errors will be back, which is highly undesirable in my humble
> opinion.
>

My argument is that the solution has more cons than pros.

Pros:

- if a package A is marked as broken, message won't end up in hydra error
tab

Cons:

- one needs to tag every package as broken, as reverse-dependencies are not
propagated (lot's of manual work)

- packages are not broken at all, just not supported -> really poor UX,
which is *important* and was the goal of the design of such error handling


>
> Generally speaking, I'm somewhat offended by this practice of announcing
> that you'll revert my commits (and then doing it without giving me a
> chance to state my point of view). It's great for you that a few hundred
> evaluation errors on Hydra don't seem to bother you, but they do bother
> me, and I don't get the impression that you take that legitimate
> interest of mine seriously.
>

I am interested into the fix. I'm working and thinking how to solve this
with less trade-offs.

I do think your solution does more harm than good currently, but I really
understand the motivation for the fix. I also
understand that conclusion is opinionated, but the good news is there are
better solutions that should hopefully satisfy everyone
in this particular case.

I'll open another thread about how to handle controversial commits.


>  > the errors are still visible on Hydra evaluation tab, but they are
>  > lying to the user that a package is broken whereas it's only not
>  > supported.
>
> It would be nice to have "meta.broken" accept an error message string
> that's used to report the failure (with the boolean "true" defaulting to
> the error error message we currently have). That way, it would be
> possible to give the user more nuanced feedback about the reasons why a
> certain package could not be installed.
>


I've opened https://github.com/NixOS/nixpkgs/issues/6561 and proposed a
somewhat more general approach,
we still need to solve the case of propagated broken/disabled packages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150225/69125cd2/attachment.html