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
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
