Installing a prerelease package using --version fails to resolve prerelease dependencies

[jberezanski]

What You Are Seeing?

(I'm fairly certain I've seen it discussed somewhere earlier, but I couldn't find any existing issue, so here it is.)

Given

1. a package main-package with a prerelease version, for example 2.0.0-pre
2. a package sub-package, also with a prerelease version, for example 1.2.3-pre
3. main-package 2.0.0-rc depends on sub-package 1.2.3-rc

invoking

choco install main-package --version 2.0.0-rc

results in failure, with choco complaining "Unable to resolve dependency 'sub-package (= 1.2.3-rc)'.".

On the other hand, if choco is invoked explicitly with --pre:

choco install main-package --version 2.0.0-rc --pre

installation succeeds

What is Expected?

When told to install a specific package version, when that version is a prerelease, choco should be able to resolve prerelease dependencies, without requiring the user to specify --pre explicitly.

How Did You Get This To Happen? (Steps to Reproduce)

choco install dotnetcore-windowshosting --version "2.1.0.20180510-rc1" -y

(source: Disqus comment)

Output Log

https://gist.github.com/jberezanski/8541f715850e387089936b44757083ca

[bcurran3]

IMHO: choco should install the dependencies specified and not attempt any "transcription" of them.

i.e. if a dependency is specified as a release version, choco installs the release version. If the dependency is specified as a pre-release version, choco installs the pre-release version. So a pre-release package with pre-release dependencies should install those pre-release dependencies because that's what was specified. IMHO It doesn't make sense for choco to install a pre-release package and then also search for pre-released dependencies if they exist. Makes more sense to define the pre-release dependencies in the pre-release package until all are released and the issue becomes moot.

Any "transcription" of dependencies would most likely cause unexpected results for packagers pushing pre-release packages using dependencies, as any installed "transcribed" pre-release dependencies seems counterintuitive to their dependency list and most likely in the case of unrelated (they don't own the dependency package) they might not know a pre-release exists.

If I understood the original issue, please forgive me and ignore this whole comment post.

[martincostello]

The package where the issue was found did define a prerelease dependency of its own, but it failed to install without --pre being specified when installing the prerelease pacakage that declared it as a dependency.

[bcurran3]

Thanks. WITH THAT SAID... it seems choco should install whatever version it's damn well told to do -pre or not! :)

[gravity00]

This has been a difficulty for our ops team for distributing release candidate software.

We use a main package, like an umbrella kinda like Microsoft does with Microsoft.AspNetCore.All, to reference the specific versions of all software installed and then the dependencies only reference the package names, so Chocolatey knows how to install the required software by the needed order. Example:

some-software.install (1.0.0)
  dotnet4.6.2 (4.6.01590.20170129)
  dotnetcore-sdk (2.2.0)
  some-software-api.install (1.0.0)
    dotnet4.6.2
    dotnetcore-sdk
  some-software-service.install (1.0.0)
    dotnet4.6.2
    some-software-api.install

If we invoke choco upgrade some-software.install --version=1.0.0 -y it will ensure not only the order is kept, but also the specific or newer versions of dependencies are installed. The problem happens when we are setting up a release candidate version. Example:

some-software.install (1.1.0-rc1)
  dotnet4.6.2 (4.6.01590.20170129)
  dotnetcore-sdk (2.2.0)
  some-software-api.install (1.1.0-rc1)
    dotnet4.6.2
    dotnetcore-sdk
  some-software-service.install (1.0.0)
    dotnet4.6.2
    some-software-api.install

If we use choco upgrade some-software.install --version=1.1.0-rc1 -y it will fail because the package some-software-api.install (=1.1.0-rc1) won't be found. If we use the --pre flag it will install the pré-release version of all dependencies (ex: dotnetcore-sdk) which isn't the intended behavior for us.

As a solution, the ops team must know what changed and invoke the choco upgrade for all packages in release candidate. This defeats the purpose of having a single package to track and manage all software dependencies.

Like @bcurran3 said, if a preview package depends on other preview packages, and they do exist, the expected behavior would be to install them. At least for me, having to explicit set the --version flag when installing a preview package should be enough to be sure the user really wants that.

[ckolumbus]

Any progress on this one (any direction)?
From my perspective I'd concur with @gravity00.

[gravity00]

Any news about this? Still having the same issues to manage