Specifying prerelease with dependencies does not work #1280

Closed
Hammerstad opened this Issue Dec 2, 2015 · 7 comments

Comments

Projects
None yet
2 participants
@Hammerstad

Paket version: 2.31.1

The names of the real packages had to be renamed in this example.

The following works

paket.dependencies:

source http://internal-proget/nuget/OurFeed

nuget My.Company.PackageA.Server prerelease
nuget My.Company.PackageB.Server prerelease

My.Company.PackageA.Server and My.Company.PackageB.Server depends on My.Company.PackageC.Server version 1.0 <= x < 2.0, but our proget server only contains prerelease packages, the latest is 1.0.0-pre18038. My.Company.PackageC.Server depends on several other packages, which have released versions.

The output when running paket.exe install is:

Paket version 2.31.1.0
Resolving packages for group Main:
 - My.Company.PackageA.Server 1.0.0-pre18038
 - My.Company.PackageB.Server 1.0.0-pre18038
 - My.Company.PackageC.Server 1.0.0-pre18038
 - Other.Package1 13.0.0-pre0248
 - Other.Package2 2.2.0-pre0105
 - Other.Package3 31.0.0-pre0280

The following does not work

We expect the list in paket.dependencies to grow quite rapdily, and in order to have an overview we want to list everything explicitly:

source http://internal-proget/nuget/OurFeed

nuget My.Company.PackageA.Server prerelease
nuget My.Company.PackageB.Server prerelease
nuget My.Company.PackageC.Server prerelease

We have tried listing all 6 packages (Other.Package*), or just the 3 in the example above. Different permutations does not seem to affect the result:

Paket version 2.31.1.0
Resolving packages for group Main:
 - My.Company.PackageA.Server 1.0.0-pre18038
 - My.Company.PackageB.Server 1.0.0-pre18038
 - My.Company.PackageC.Server 1.0.0-pre18038
 - My.Company.PackageC.Server 1.0.0-pre18036
 - My.Company.PackageA.Server 1.0.0-pre18036
Paket failed with:
        There was a version conflict during package resolution.
  Resolved packages:
   - My.Company.PackageA.Server 1.0.0-pre18036
   - My.Company.PackageC.Server 1.0.0-pre18036
  Could not resolve package My.Company.PackageC.Server:
   - Dependencies file requested: >= 0
   - My.Company.PackageA.Server 1.0.0-pre18038 requested: >= 1.0 < 2.0 (no prereleases)

  Please try to relax some conditions.
@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 2, 2015

Member

My.Company.PackageA.Server and My.Company.PackageB.Server depends on My.Company.PackageC.Server version 1.0 <= x < 2.0

shouldn't it explicitly depend on the prerelease versions?

Member

forki commented Dec 2, 2015

My.Company.PackageA.Server and My.Company.PackageB.Server depends on My.Company.PackageC.Server version 1.0 <= x < 2.0

shouldn't it explicitly depend on the prerelease versions?

@Hammerstad

This comment has been minimized.

Show comment
Hide comment
@Hammerstad

Hammerstad Dec 2, 2015

shouldn't it explicitly depend on the prerelease versions?

This could be a solution, but not one we're particulary willing to use, since it would mean updating all dependencies when we release. Our company has hundreds of unique packages, so this would be quite a lot of work.

We could always specify a range like 0.9.32767 <= x < 2.0, but that feels like an ugly hack.

The reason I'm asking is because Paket resolved the dependencies in the first example (the same does nuget and chocolatey when provided the -Pre flag). We were wondering why the second example failed. The paket.lock file looks like this:

remote: http://internal-proget/nuget/OurFeed
specs: 
    My.Company.PackageA.Server (1.0.0-pre18038)
      My.Company.PackageC.Server (>= 1.0 < 2.0)
    My.Company.PackageB.Server (1.0.0-pre18038)
      My.Company.PackageC.Server (>= 1.0 < 2.0)
    My.Company.PackageC.Server (1.0.0-pre18038)
      Other.Package2 (> 2.0.0 <= 3.0.0)
      Other.Package1 (> 13.0.0 <= 14.0.0)
      [...]

shouldn't it explicitly depend on the prerelease versions?

This could be a solution, but not one we're particulary willing to use, since it would mean updating all dependencies when we release. Our company has hundreds of unique packages, so this would be quite a lot of work.

We could always specify a range like 0.9.32767 <= x < 2.0, but that feels like an ugly hack.

The reason I'm asking is because Paket resolved the dependencies in the first example (the same does nuget and chocolatey when provided the -Pre flag). We were wondering why the second example failed. The paket.lock file looks like this:

remote: http://internal-proget/nuget/OurFeed
specs: 
    My.Company.PackageA.Server (1.0.0-pre18038)
      My.Company.PackageC.Server (>= 1.0 < 2.0)
    My.Company.PackageB.Server (1.0.0-pre18038)
      My.Company.PackageC.Server (>= 1.0 < 2.0)
    My.Company.PackageC.Server (1.0.0-pre18038)
      Other.Package2 (> 2.0.0 <= 3.0.0)
      Other.Package1 (> 13.0.0 <= 14.0.0)
      [...]
@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 2, 2015

Member

Yes we resolve it since only prerelease packages are available. There is
not a single "release" of that package, right?
If this is the case then it tries to be a bit more tolerant.

That said: I can try to create a repro case with the versions you gave.
Maybe we find a way around it.
But still you should consider to update the requirements in the nuspecs.

What is nuget.exe doing in this case?
On Dec 2, 2015 15:06, "Eirik Mildestveit Hammerstad" <
notifications@github.com> wrote:

shouldn't it explicitly depend on the prerelease versions?

This could be a solution, but not one we're particulary willing to use,
since it would mean updating all dependencies when we release. Our company
has hundreds of unique packages, so this would be quite a lot of work.

We could always specify a range like 0.9.32767 <= x < 2.0, but that feels
like an ugly hack.

The reason I'm asking is because Paket resolved the dependencies in the
first example (the same does nuget and chocolatey when provided the -Pre
flag). We were wondering why the second example failed. The paket.lock
file looks like this:

remote: http://internal-proget/nuget/OurFeed
specs:
My.Company.PackageA.Server (1.0.0-pre18038)
My.Company.PackageC.Server (>= 1.0 < 2.0)
My.Company.PackageB.Server (1.0.0-pre18038)
My.Company.PackageC.Server (>= 1.0 < 2.0)
My.Company.PackageC.Server (1.0.0-pre18038)
Other.Package2 (> 2.0.0 <= 3.0.0)
Other.Package1 (> 13.0.0 <= 14.0.0)
[...]


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

Member

forki commented Dec 2, 2015

Yes we resolve it since only prerelease packages are available. There is
not a single "release" of that package, right?
If this is the case then it tries to be a bit more tolerant.

That said: I can try to create a repro case with the versions you gave.
Maybe we find a way around it.
But still you should consider to update the requirements in the nuspecs.

What is nuget.exe doing in this case?
On Dec 2, 2015 15:06, "Eirik Mildestveit Hammerstad" <
notifications@github.com> wrote:

shouldn't it explicitly depend on the prerelease versions?

This could be a solution, but not one we're particulary willing to use,
since it would mean updating all dependencies when we release. Our company
has hundreds of unique packages, so this would be quite a lot of work.

We could always specify a range like 0.9.32767 <= x < 2.0, but that feels
like an ugly hack.

The reason I'm asking is because Paket resolved the dependencies in the
first example (the same does nuget and chocolatey when provided the -Pre
flag). We were wondering why the second example failed. The paket.lock
file looks like this:

remote: http://internal-proget/nuget/OurFeed
specs:
My.Company.PackageA.Server (1.0.0-pre18038)
My.Company.PackageC.Server (>= 1.0 < 2.0)
My.Company.PackageB.Server (1.0.0-pre18038)
My.Company.PackageC.Server (>= 1.0 < 2.0)
My.Company.PackageC.Server (1.0.0-pre18038)
Other.Package2 (> 2.0.0 <= 3.0.0)
Other.Package1 (> 13.0.0 <= 14.0.0)
[...]


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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 2, 2015

Member

(OK I can reproduce your case and try to investigate)

Member

forki commented Dec 2, 2015

(OK I can reproduce your case and try to investigate)

@forki forki added the bug label Dec 2, 2015

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 2, 2015

Member

I assume it's really a bug.

Member

forki commented Dec 2, 2015

I assume it's really a bug.

@forki forki closed this in acfb5b4 Dec 2, 2015

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 2, 2015

Member

could you please check if it now works for you?

Member

forki commented Dec 2, 2015

could you please check if it now works for you?

@Hammerstad

This comment has been minimized.

Show comment
Hide comment
@Hammerstad

Hammerstad Dec 3, 2015

Works like a charm!
Thank you for the quick response 😄

Works like a charm!
Thank you for the quick response 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment