pin dependencies when building a package

[ilanschnell]

In this PR, we add the ability to create packages which list the exact versions which get installed into the test environment, even when the recipe itself does not specify those versions, using:

build:
  pin_depends: strict

The integer may be set to one of the following values:

• record: only record the exact distributions in info/requires
• strict: use exact specs (name version build_string) in depends for all packages.

[pelson]

What's the use case @ilanschnell? This sounds like may be a catch-all for badly written recipes...?

[ilanschnell]

The use case is for deploying large "applications" to customers, where we want to make sure all packages are explicitly specified (to ensure nothing breaks due to different versions), in the same way "anaconda" is deployed. When you "conda install anaconda=2.3.0", all packages are specified by version and build string, and there is no question whether you (for example ) get python-2.7.8-1 or python-2.7.10-0.

[msarahan]

Then why not create an application metapackage for that customer, like
anaconda?

On Wed, Jan 27, 2016, 08:07 Ilan Schnell notifications@github.com wrote:

The use case is for deploying large "applications" to customers where we
want to make sure all packages are explicitly specified (to ensure nothing
breaks due to different versions), in the same way "anaconda" is deployed.
When you "conda install anaconda=2.3.0", all packages are specified by
version and build string, and there is no question whether you (for example
)get python-2.7.8-1 or python-2.7.9-0.

—
Reply to this email directly or view it on GitHub
#741 (comment).

[ilanschnell]

Yes, this is basically what this can be used for (whether you create a meta-package or a real package). The point of this PR is to make it easier to "bake" the fully specified dependencies in.

[srossross]

Ilan this looks great. Thanks

[srossross]

Can 'record' be the default?

[ilanschnell]

I don't want to make record the default, as it takes up extra compute time, because the resolver has to be called another time.

[kalefranz]

Add in comment here that pin_depends is an alpha feature with names/api/etc subject to change.

[pelson]

The use case is for deploying large "applications" to customers, where we want to make sure all packages are explicitly specified (to ensure nothing breaks due to different versions), in the same way "anaconda" is deployed. When you "conda install anaconda=2.3.0", all packages are specified by version and build string, and there is no question whether you (for example ) get python-2.7.8-1 or python-2.7.10-0.

Thanks @ilanschnell. Makes sense from an anaconda point of view. Interestingly though, this is essentially the same functionality as defining an environment (i.e. conda env export). The functionality being added here does further blur the line between a meta package and an environment, though I wouldn't go as far as saying that was a showstopper.

In terms of implementation, I have to say that I feel the code regresses some of the interfaces - essentially it rolls back some of the correctly encapsulated capabilities and replaces it with globals. Is there a strong reason for that @ilanschnell, or is it more a matter of making pragmatic choices?

@kalefranz, where do you sit on this one?

[ilanschnell]

Thanks @pelson for the feedback. The globals that I have introduced should have been gloabls from the beginning, I think. It is much cleaner (and less code) to set these variables once, rather than passing them between the various functions all the time. The variables are set by the user in the CLI, so they will not change during the running process. This is exactly where globals come in handy.