Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Packing with prerelease dependencies #1316
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
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,
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.
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.
added a commit
Dec 29, 2015
Sorry for the delay, here is a repro sample : https://github.com/franknarf8/paket-issue-repro/tree/d75918899bc5d65d90dc2cc36bbe847c68814590
Thanks, but I think there is still an issue.
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.
As the package version timeline goes like so :
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)"
[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 email@example.com:
That is awesome, thanks a lot!
Now I think there may still be an issue with the ~> operator for prereleases.
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 :
I think B dependency should be this following range [2.0.0-prerelease, 3.0.0).
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 :
(and not with the following ones : 2.0.0-alpha, 3.0.0)