justanotheruser has quit [Ping timeout: 260 seconds]
<ris>
that's weird. anyone ever experience the `checkInputs` of a python package leaking into the install phase?
<ris>
just removed all the checkInputs from a (very simple) package & all of a sudden the _install_ won't pass as it's missing dependencies
<worldofpeace>
ris: sometimes that's because of a setup requires being in checkinputs
<ris>
interesting - but would that have been picked up as a propagated package then or would we have ended up with a package missing deps?
<ris>
all seems like a bit of a footgun
worldofpeace_ has joined #nixos-dev
justanotheruser has joined #nixos-dev
worldofpeace_ has quit [Client Quit]
alp has quit [Ping timeout: 260 seconds]
<adisbladis>
ris: Welcome to Python packaging.. It's full of footguns.
<adisbladis>
It would have resulted in a missing dep
<ris>
:(
<ris>
so... is this because we put a special rule in to allow things like the pytest-runner to be a checkInput?
<adisbladis>
ris: I don't understand the question?
<ris>
the classic pain with pytest-runner is it had to be used by adding it as a setup_requires to allow it to modify the behaviour of setup.py itself
<ris>
which used to mean that people had to add it as a buildInput
<ris>
or worse, a propagatedBuildInput
<adisbladis>
Yeah?
<ris>
was a special exception put in for that? otherwise i don't see how a checkInput would ever be injected in any case other than the checkPhase
<adisbladis>
ris: Inputs are not phase scoped.
<adisbladis>
A checkInput is just an input which is conditional on doCheck
<ris>
say what
<ris>
you've just blown my mind
<adisbladis>
`checkInputs = [ pytest-runner ]` is exactly the same as `buildInputs = [ pytest-runner ]` provided `doCheck = true`
<ris>
that's disappointing to learn
<ris>
and a bit worrying
<adisbladis>
ris: Basically you should think of Nix as something that generates a sandboxed shell script, and phases are shell script functions
<ris>
i thought simply the checkPhase might be run in a subshell that just had a different set of PATH/PYTHONPATH/etc set
<adisbladis>
Nope.. That would probably be possible, but it's not the case.
<ris>
seems like it would help people to build safer packages
<ris>
i guess it's less of an issue for e.g. native packages because of the different way their output dependencies are determined
<sorear>
safer in what sense
<ris>
well in the python case, allowing something that should be injected as a propagatedBuildInput appear satisfied because it was supplied as a checkInput
<ris>
end result, package that has a missing dependency
<ris>
but all its tests pass happily
<worldofpeace>
adisbladis: I believe it's actually native build inputs since a while ago
<adisbladis>
worldofpeace: That makes sense =)
<ris>
becuase it's easy to think "well, people shouldn't do that/people need to be more careful", but so much of the time people end up having to bump/fixup packages they know little about. and after passing through 5 different random people's bump attempts, the purpose of each input starts to get blurred.
<ris>
or even a r-ryantm auto-bump
orivej has quit [Read error: Connection reset by peer]
orivej_ has joined #nixos-dev
<ris>
a version bump subtly moves a dependency from just a test dependency to a full dependency
<ris>
package appears to continue to be fine
<ris>
tests pass
<ris>
i guess it would be possible to do an occasional scan for packages with these problems by building with e.g. doCheck = false forced