Paket pack with LOCKEDVERSION uses slightly different version #1257

Closed
pdfforge opened this Issue Nov 25, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@ghost

ghost commented Nov 25, 2015

We are using an internal dependency called pdfcmon with a specific version 0.8.4.0. The .lock file states:

 pdfcmon (0.8.4.0)

The template file states:

 dependencies
     pdfcmon = LOCKEDVERSION

In the Nuspec it is generated as:

  <dependency id="pdfcmon" version="[0.8.4]" />

This leads to an error when installing the packages:

 Paket failed with:
 Couldn't get package details for package pdfcmon 0.8.4

Retrieving the package version 0.8.4.0 works just fine. For our internal dependencies, we use Klondike as NuGet feed. The main question is: Whose "fault" is this? Should Klondike recognize that 0.8.4.0 and [0.8.4] are the same? On the other hand: It would make sense to not omit the last zero in the spec file as it can be significant.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Nov 25, 2015

Member

At the moment we write "normalized versions" into the output. Klondike
should understand that, since it's a nuget standard. But to make things
compatible we can probably change that and write the original version.
On Nov 25, 2015 12:51 PM, "pdfforge" notifications@github.com wrote:

We are using an internal dependency called pdfcmon with a specific version
0.8.4.0. The .lock file states:

pdfcmon (0.8.4.0)

The template file states:

dependencies
pdfcmon = LOCKEDVERSION

In the Nuspec it is generated as:

This leads to an error when installing the packages:

Paket failed with:
Couldn't get package details for package pdfcmon 0.8.4

Retrieving the package version 0.8.4.0 works just fine. For our internal
dependencies, we use Klondike as NuGet feed. The main question is: Whose
"fault" is this? Should Klondike recognize that 0.8.4.0 and [0.8.4] are the
same? On the other hand: It would make sense to not omit the last zero in
the spec file as it can be significant.


Reply to this email directly or view it on GitHub
#1257.

Member

forki commented Nov 25, 2015

At the moment we write "normalized versions" into the output. Klondike
should understand that, since it's a nuget standard. But to make things
compatible we can probably change that and write the original version.
On Nov 25, 2015 12:51 PM, "pdfforge" notifications@github.com wrote:

We are using an internal dependency called pdfcmon with a specific version
0.8.4.0. The .lock file states:

pdfcmon (0.8.4.0)

The template file states:

dependencies
pdfcmon = LOCKEDVERSION

In the Nuspec it is generated as:

This leads to an error when installing the packages:

Paket failed with:
Couldn't get package details for package pdfcmon 0.8.4

Retrieving the package version 0.8.4.0 works just fine. For our internal
dependencies, we use Klondike as NuGet feed. The main question is: Whose
"fault" is this? Should Klondike recognize that 0.8.4.0 and [0.8.4] are the
same? On the other hand: It would make sense to not omit the last zero in
the spec file as it can be significant.


Reply to this email directly or view it on GitHub
#1257.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 25, 2015

After digging into the HTTP traffic, I see two requests. The first is for the normalized version:

 GET /api/odata/Packages?$filter=(Id%20eq%20'pdfcmon')%20and%20(NormalizedVersion%20eq%20'0.8.4')

Klondike does not understand this and return HTTP 400.

The second is for a specific version:

 GET /api/odata/Packages(Id='pdfcmon',Version='0.8.4')

Klondike gives a 404 here, as this precise version is not available.

ghost commented Nov 25, 2015

After digging into the HTTP traffic, I see two requests. The first is for the normalized version:

 GET /api/odata/Packages?$filter=(Id%20eq%20'pdfcmon')%20and%20(NormalizedVersion%20eq%20'0.8.4')

Klondike does not understand this and return HTTP 400.

The second is for a specific version:

 GET /api/odata/Packages(Id='pdfcmon',Version='0.8.4')

Klondike gives a 404 here, as this precise version is not available.

@forki forki closed this in cb8b897 Nov 27, 2015

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