On Wed, Jul 11, 2012 at 2:10 PM, Mathijs Kwik <[email protected]>wrote:
> Bryce L Nordgren <[email protected]> writes: > > > On Wed, Jul 11, 2012 at 12:53 AM, Mathijs Kwik <[email protected]> > wrote: > > > > There may be a couple of things I didn't articulate well. > > > > 1] I don't see these new semantics as "either/or". I fully expect you to > be able to declare a weak dependency on > > the python environment and a "depends on exact build of" for the imaging > thingy. > > 2] I would envision the semantics of java packages to other java > packages to be "depends on exact build of". > > It's the dependency on the environment which needs to be weaker. > > I understand that part, but even using a weak dependency on environments > can lead to problems. Essentially these "weak" dependencies are > like a flag to tell the resolver "do not rebuild, although you think you > should, I know better". I know that in some cases, this indeed is the > case, but in many subtle cases, it really isn't. > I believe the current situation is "this package is completely unrelated to the environment in which it runs. Do not rebuild. Don't even install the environment automatically." At least, this would be the result of adopting a strategy like only referring to the JRE using "$JAVA_HOME/bin/java". The weak dependencies allow a completely missing dependency to be specified. I think we have different "starting points" in mind. Do python packages currently depend on python? Note: with java the compiler which builds a package is packaged as a JDK. The runtime environment could either be a jdk or a jre. It doesn't make a lot of sense to force all packages to depend on a specific build of the jdk when that might not be where it's running. And to make matters worse: you can compile using JDK 1.6 with a "-target 1.4" flag on the compiler. That will be buried in the ant or maven configuration file and will never be exposed as a parameter Nix can get its hands on. If this is the case, is it even appropriate to say that the result depends on jdk 1.6? Is it beneficial to recompile this package simply because we upgrade to 1.7? Not sure I know the answer to these questions. > In the "weak dep on python" case however, MyPackage doesn't rebuild > (because only python changed), so its build script will not run to > detect breakage. Only far later, when I try to run MyPackage on some > production server, I find out this problem. > Sometimes (often?) build scripts don't detect this kind of problem. Things which are coded against an API and just use whatever providers are available at runtime are designed not to break at build time when a particular provider is missing. It's only when someone tries to exercise a specific provider (specified via a preferences file for database connections, or when autodetecting a file format when opening a particular file) that this class of problem spits out an error. I wouldn't count on strong dependencies on particular build artifacts to help you out here. ;) Many times the user is responsible for separately downloading and making available the specific provider they need at the time of deployment. > To fix this, MyPackage's nix expression should capture the fact that it > depends on Python being built with ImageThingy support. > Correct. I do not see any difference between specifying a dependency on optional parts of an environment and specifying a dependency on other python libraries. (After all, 3rd party libraries are just optional extensions to the non-optional environment.) You'd have to add dependent libraries to the MyPackage parameter list, why shouldn't you have to ensure MyPackage sets a flag on the environment? So, it looks like maybe a "parameterized weak dependency" may be in order, where you list both the environment and the optional components to the environment? The particular build of the environment still does not matter as long as the environment includes (at least) the correct set of optional components. Bryce
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
