Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
On Tue, Feb 24, 2015 at 4:29 PM, Peter Simons sim...@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
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
I've reverted the behavior in
https://github.com/NixOS/nixpkgs/commit/b653e3f6614fbe2664b1fd09d3baf5222b4de7f2
I'll take a look how to improve Hydra not to emit those messages in errors
tab.
On Wed, Feb 25, 2015 at 9:18 AM, Domen Kožar do...@dev.si wrote:
On Tue, Feb 24, 2015 at 4:29 PM, Peter Simons sim...@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
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
Could we agree than that using throw with a custom message is better than marking the build as broken? Also, I've seen that throw does propagate. The package is disabled if it depends on another package. The TODO would be for hydra to filter out some error messages. On Tue, Feb 24, 2015 at 8:45 PM, Vladimír Čunát vcu...@gmail.com wrote: On 02/24/2015 04:44 PM, Vladimír Čunát wrote: On 02/24/2015 04:33 PM, Luca Bruno wrote: Afaik it's not only a python disabled problem. It also happens for meta.broken that doesn't get propagated. Yes, one great advantage of throw is how it propagates nicely. Is there a reason not to use that, except for errors in Hydra evals? We might just tweak/customize error-logging from the current throw instead of doing anything complex. Oh, I've let you mislead me (and my memory just returned): meta.broken is implemented via throw run as an assertion in stdenv.mkDerivation evaluation. See nixpkgs/pkgs/stdenv/generic/default.nix for the implementation. Therefore, it certainly should get propagated whenever anything from the derivation is used (even just name or meta stuff). If we need another semantically distinct option, like meta.disabled, it will be easy to implement in the same way. However, for any throw-based solutions, Hydra just outputs the error thrown, so we that's a point where it should get more clever. Perhaps we could be having some tags at the start of the string, such as Broken: or Disabled:, so Hydra or anyone could easily filter the throws and keep only the ones interesting in the particular use case. Vladimir ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
On 02/24/2015 04:44 PM, Vladimír Čunát wrote: On 02/24/2015 04:33 PM, Luca Bruno wrote: Afaik it's not only a python disabled problem. It also happens for meta.broken that doesn't get propagated. Yes, one great advantage of throw is how it propagates nicely. Is there a reason not to use that, except for errors in Hydra evals? We might just tweak/customize error-logging from the current throw instead of doing anything complex. Oh, I've let you mislead me (and my memory just returned): meta.broken is implemented via throw run as an assertion in stdenv.mkDerivation evaluation. See nixpkgs/pkgs/stdenv/generic/default.nix for the implementation. Therefore, it certainly should get propagated whenever anything from the derivation is used (even just name or meta stuff). If we need another semantically distinct option, like meta.disabled, it will be easy to implement in the same way. However, for any throw-based solutions, Hydra just outputs the error thrown, so we that's a point where it should get more clever. Perhaps we could be having some tags at the start of the string, such as Broken: or Disabled:, so Hydra or anyone could easily filter the throws and keep only the ones interesting in the particular use case. Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
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.
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?
Best regards,
Peter
[1] http://hydra.nixos.org/jobset/nixpkgs/trunk#tabs-errors
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
Hi Luca, Afaik it's not only a python disabled problem. It also happens for meta.broken that doesn't get propagated. yes, that is true. I guess the problems shows up with Python more than other packages because Python has many different active environments: Py2k, Py3k, PyPy. The Haskell package set used to have the same problem, but the NG effort remedied that by generating the entire package set programmatically to be consistent. python-packages.nix is maintained manually, though, so it's easier for those packages to have inconsistent specifications. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
On 24/02/2015 16:29, Peter Simons 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.
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?
Best regards,
Peter
Afaik it's not only a python disabled problem. It also happens for
meta.broken that doesn't get propagated.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
On 02/24/2015 04:33 PM, Luca Bruno wrote: Afaik it's not only a python disabled problem. It also happens for meta.broken that doesn't get propagated. Yes, one great advantage of throw is how it propagates nicely. Is there a reason not to use that, except for errors in Hydra evals? We might just tweak/customize error-logging from the current throw instead of doing anything complex. Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
