[Nix-dev] Dependency Semantics

[Bryce L Nordgren]

I'm not saying you shouldn't. But the current build system finds out
> about the breakage, so the maintainer can investigate and put the extra
> dependency there. You have to understand that most package expressions
> are probably created as a bare minimum, just adding the stuff the
> builder/installer complains about. This works fine most of the time.
> So in this case, where (up till now) just depending on python sufficed,
> there's probably only python in the dependency list. For all we know,
> the python maintainer will take care all the optional parts get built
> anyway. If this changes in the future, I would like to find out
> automatically.
>

Well, I think two different cases are getting mixed up here. I'm talking
about a rebuild of the exact same python Nix expression, and you're talking
about the python Nix expression evolving over time. It's certainly possible
to treat the two cases differently, probably even desirable.

For instance, python code could have a "recompile only when the python
version is changed"  semantics. Or "recompile whenever the python nix
expression changes in any way". Either of these would put a halt to
cascading pointlessness when a third generation dependency of the python
interpreter causes the same interpreter to be rebuilt; both would provide
the automatic checks you desire when something important changes about the
environment.



> This sounds like a problem to me, one that the current semantics solve
> by saying "if any inputs change, we want to make sure everything is
> still fine (up to the level that upstream build/test scripts would
> accept).
>

The new semantics really only apply to these environments intended to serve
as an isolation layer between the host system and code which executes in
the environment. I realize none of them will provide perfect isolation and
you can all find exceptions to the rule. However, many codes can run
unchanged on Windows/Linux/Mac: in java's case, many compiled binaries can
run unchanged on Linux/Windows/Mac and it is actually pretty rare to
rebuild from source. A finished java app is commonly compiled by a variety
of JDK versions on a variety of different platforms. In any case, the exact
version of glibc (and a host of other 2nd, 3rd ... generation dependencies)
on the system is pretty irrelevant--windows doesn't even have glibc at all!

The relevant question is: What is more common--that the isolation is
effective or that it isn't? So, let me quote you:

"You have to understand that most package expressions are probably created
as a bare minimum, just adding the stuff the builder/installer complains
about."

I would suggest that the "bare minimum" is to declare that a python package
depends on python with "recompile when the python version number changes"
semantics. If a particular package proves problematic, strengthen the
dependency semantics for that package to depend on a specific python build.
Then it's always rebuilt.

You still get a full rebuild every time the environment is upgraded, but
you don't rebuild everything whenever the same environment is rebuilt. Also
anything with "native code" (linking directly against a system library,
subverting the isolation layer) should have a dependency on the specific
build of the library it links to, causing a rebuild of that module as well
as any other python modules which depend on it. As you said, the Nix
builder will fail if the system library is missing, so the packager will be
forced to add it.

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120712/a5a0a678/attachment.html