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

[Domen Kožar]

On Tue, Feb 24, 2015 at 4:29 PM, Peter Simons <simons at cryp.to> wrote:

> Hi guys,
>
> many Python packages specify an attribute that disables build attempts
> in certain packages sets, like this:
>
>     beaker = buildPythonPackage rec {
>       name = "Beaker-1.6.4";
>       disabled = isPy3k;
>       [...]
>     };
>
> Unfortunately, that information does not propagate to other packages
> that use them. The package "almir", for instance, depends on "beaker"
> but *allows* Python 3.x builds. The result is an evaluation error on
> Hydra:
>
>     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
https://github.com/NixOS/nixpkgs/commit/79a5fec9c053a0b1303e121060a839d4b9ec2e55

At the end it's the same thing, throw/broken does propagate to
dependencies. Previously dependencies would be marked as unsupported, now
they are marked as broken.


> As of now, we have dozens of those errors in [1]. I have tried to make
> some headway getting rid of those errors, but manually fixing all those
> under-specified "disabled" attributes is a bit of fools errand, because
> without a doubt those specifications will become inconsistent again over
> time!
>
> Now, we should really try to have Zero evalutation errors on Hydra,
> because those "false" messages drown out real errors, which would need
> fixing. I'm not particularly involved in the maintenance of the Python
> package set, so I'd like to bring this issue to the attention of those
> who know more about Python and work more with Python in Nixpkgs than I
> do. Can we solve this issue somehow in a way that doesn't require human
> beings to fix everything manually?


The errors are not the issue of Python packaging but rather how Hydra
handles evaluation errors.

'throw' is currently the only way to stop evaluation with a custom error
message.

'throw' is used for Python packaging to note that interpreter is not
supported

'throw' is used for meta.broken to note if a package is broken.

I'm reverting
https://github.com/NixOS/nixpkgs/commit/79a5fec9c053a0b1303e121060a839d4b9ec2e55
and sequential commits as they don't improve the situation,
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.

Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150225/fc330db0/attachment.html