Packing with prerelease dependencies

[franknarf8]

Hello,

Firstly, I want to mention I have been using Paket for a little while now and love the software.

Here is my problem,

I have 3 projects (A, B, C) where
B depends on (A 2.0 prerelease)
C depends on (B 1.0 prerelease)

A, B are libraries and are shipped in their respective nuget packages created using Paket. We are using SemVer with prerelease tags. (using GitFlow)

Nuget packages for A are usually named something like "A 1.0-unstable0021"

Projects B resolve correctly its dependency to A on "paket update". When we use "paket pack" for package B, it creates the following nuget dependencies,
A( = 1.0.0-prerelease)

The thing is, when we try to "paket update" C, it cannot resolve A. I think he is is looking for a package versionned exactly "1.0.0-prerelease".

(The problem also applies to prerelease ranges (~>, <, >, etc.))

I don't quite know how to solve this problem. Maybe it is a comprehension issue, but if it is not, I'd be happy to contribute.

[forki]

I think we create a wrong version requirement here. Do you know what NuGet would create in package B?

[franknarf8]

I'm not quite sure, but from what I understood, there are no prerelease information injected in the dependency version requirement.

In the previous example, B should only have a dependency on A with version "1.0.0", not "1.0-prerelease". Then, if we pull on a stable version of package B, it should pull a stable version of B and a stable version of A (e.g. "A 1.0.0"). Likewise, if we specify the B package to be unstable in the .dependencies file, it should pull on the latest version of B and A (including prereleases, but not excluding stable releases, e.g. "A 1.0.0-unstableXX).

The applications for "=" dependencies are not that numerous, but the applications for dependency ranges are a bit more problematic.

[forki]

I'm investigating the case - It's seems to be a bug, but I don't think the solution is like what you describe. Prerelease flags are not transitive across packages and their dependencies.

[forki]

I fixed a bug in this area in 2.39.9 but I assume it's not directly the one that impacts you.
Can please try to create a repro sample? That would help me a lot

[franknarf8]

Sorry for the delay, here is a repro sample : https://github.com/franknarf8/paket-issue-repro/tree/d75918899bc5d65d90dc2cc36bbe847c68814590

[forki]

wow very cool repro sample. Looks like a very very strange edge case.

If you repack B with the latest Paket version then it should work.

[franknarf8]

Thanks, but I think there is still an issue.
If I understood the fix correctly, the package B was repacked and the condition changed from "A (= 2.0.0-prerelease)" to "A (>= 2.0.0-prerelease)".

Thing is, now if the official A.2.0.0 package is out and A.2.1.0-unstableN also exists, the constraint "B depends on (A 2.0 prerelease)" won't be respected as the package A.2.1.0-unstableN will be selected.

I updated the repro repo.

[franknarf8]

Should I open a new issue? @forki

[forki]

the question is: what dependency would we need then?

[forki]

"A (>= 2.0.0-prerelease < 2.0.1)" ?

[franknarf8]

As the package version timeline goes like so :
A.1.0.0
A.2.0.0-unstable2
A.2.0.0-unstable3
A.2.0.0
A.2.1.0-unstable1

I think the constraint "B depends on (A 2.0 prerelease)" should resolve to the closest thing to A.2.0.0. In this case, the possible answers would be [A.2.0.0-unstable2, A.2.0.0-unstable3, A.2.0.0].

I'm not quite sure how to represent this range though. Maybe something like "A (>= 2.0.0-prerelease <= 2.0.0)"

[franknarf8]

But even then, it depends on how ">= 2.0.0-prerelease" is evaluated.
If the prerelease section of the range is evaluated alphabetically, A.2.0.0-unstable2 would be a candidate, but A.2.0.0-alpha1 would not, even if it is a prerelease package...

[forki]

[2.0.0-prerelease,2.0.0] works with your sample. I will create a hotfix

[forki]

released

[franknarf8]

I just tested it, it works for everything between A.2.0.0-prerelease and A.2.0.0.

Thing is now, if I only have a package A.2.0.0-alpha2, it will be ignored and resolution will crash as it is not in the range.

[franknarf8]

We would need the smallest valid prerelease name for the min delimiter in [2.0.0-prerelease,2.0.0]...

[forki]

[2.0.0-prerelease,2.0.0] should match 2.0.0-alpha2 - that's another bug

2016-01-07 18:58 GMT+01:00 franknarf8 notifications@github.com:

We would need the smallest valid prerelease name for the min delimiter in
[2.0.0-prerelease,2.0.0]...

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

[forki]

ok this is now fixed as well.

[franknarf8]

That is awesome, thanks a lot!

Now I think there may still be an issue with the ~> operator for prereleases.
I changed the B dependency on A to be "A ~> 2.0 prerelease". I also created packages A.3.0.0-alpha1.

B resolves correctly to A.3.0.0-alpha1 and creates a package with the following dependency "A(>= 2.0.0-prerelease && < 3.0.0-prerelease)"

Unfortunately C still resolves A to A.2.1-unstable1 instead of A.3.0.0-alpha1.

See this commit :
franknarf8/paket-issue-repro@4b677d3

I think B dependency should be this following range [2.0.0-prerelease, 3.0.0).

[forki]

why should ~> 2.0 resolve to 3.0?

[franknarf8]

Not to 3.0, but 3.0-alpha. I thought "~> 2" meant everything in the range "[2,3)" and since A.3.0.0-alpha1 < A.3.0.0, it is in the "[2,3)" range.

Correct me if I'm wrong, but should "~> 2.0 prerelease" or "[2.0, 3) prerelease" be compatible with the following packages :
2.0.0
2.1.0-alpha
2.1.0
3.0.0-alpha

(and not with the following ones : 2.0.0-alpha, 3.0.0)

[forki]

no we should not accept 3.0 prereleases when using ~> 2 since it will probably already break.

[franknarf8]

Ok, that makes sense. But then, B should not resolve "~> 2 prerelease" to 3.0.0-alpha1 then, right?

[forki]

yes ~> 2 should not resolve 3.0.0-alpha1 - are we doing this?

[franknarf8]

Yes : franknarf8/paket-issue-repro@4b677d3

[forki]

ouch. will fix later tonight ;-)

[franknarf8]

Ok, if I understood properly, "~> 2.0 prerelease"
Matches :
2.0
2.1-alpha
2.1
2.2

Does not match :
2.0-alpha
3.0-alpha
3.0

Right?

[franknarf8]

Ok cool, thanks!

[forki]

"~> 2.0 prerelease" should match 2.0-alpha