[Nix-dev] Dependency Semantics

[Bryce L Nordgren]

On Wed, Jul 11, 2012 at 2:10 PM, Mathijs Kwik <mathijs at bluescreen303.nl>wrote:

> Bryce L Nordgren <bnordgren at gmail.com> writes:
>
> > On Wed, Jul 11, 2012 at 12:53 AM, Mathijs Kwik <mathijs at bluescreen303.nl>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120711/35cfe5b3/attachment.html