New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error while parsing <dependency id="Newtonsoft.Json" version="*" /> #2266

Closed
ctaggart opened this Issue Apr 20, 2017 · 11 comments

Comments

Projects
None yet
3 participants
@ctaggart
Contributor

ctaggart commented Apr 20, 2017

Description

Paket version 4.5.0

Paket failed with:
        Cannot load C:\Users\CameronTaggart\tachyus\thermion\packages\JWT\JWT.nuspec
Message: Error while parsing *
Message: Can't parse "*".
Input string was not in a correct format.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>JWT</id>
    <version>2.3.1</version>
    <authors>John Sheehan, Michael Lehenbauer, Alexander Batishchev</authors>
    <owners>johnsheehan, devinrader, abatishchev</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <licenseUrl>https://creativecommons.org/publicdomain/zero/1.0/</licenseUrl>
    <projectUrl>https://github.com/jwt-dotnet/jwt</projectUrl>
    <description>Jwt.Net, a JWT (JSON Web Token) implementation for .NET</description>
    <copyright>Public Domain</copyright>
    <language>en-US</language>
    <tags>jwt json</tags>
    <dependencies>
      <dependency id="Newtonsoft.Json" version="*" />
    </dependencies>
  </metadata>
</package>

Repro steps

Please provide the steps required to reproduce the problem

nuget JWT 2.3.1

If possible then please create a git repository with a repro sample or attach a zip to the issue.

Expected behavior

I'm not sure if this is a nuspec authoring error or a paket error.

Actual behavior

Known workarounds

nuget JWT 1.3.4
@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Apr 20, 2017

Member

I think they changed something to allow this nightmare. A fix is underway - but will take some time since I want to run all integration tests

Member

forki commented Apr 20, 2017

I think they changed something to allow this nightmare. A fix is underway - but will take some time since I want to run all integration tests

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Apr 20, 2017

Member

NOTE: Someone should do it properly - I just fixed the error. but it seems nuget ranges are now changed and our parser needs adjustments

Member

forki commented Apr 20, 2017

NOTE: Someone should do it properly - I just fixed the error. but it seems nuget ranges are now changed and our parser needs adjustments

@forki forki added the up-for-grabs label Apr 20, 2017

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Apr 20, 2017

Member

also related: 1575266

Member

forki commented Apr 20, 2017

also related: 1575266

@forki forki closed this in 3b8047e Apr 20, 2017

@forki forki reopened this Apr 20, 2017

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Apr 20, 2017

Member

reopened in order to let someone else fix it properly. but paket 4.5.1 release build is running and reported error will be fixed

Member

forki commented Apr 20, 2017

reopened in order to let someone else fix it properly. but paket 4.5.1 release build is running and reported error will be fixed

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Apr 20, 2017

Member

ok fix is released.

Member

forki commented Apr 20, 2017

ok fix is released.

@fsoikin

This comment has been minimized.

Show comment
Hide comment
@fsoikin

fsoikin Jul 2, 2017

Contributor

Reading the nuspec/nuget/dotnet docs, I can't find any references to using a wildcard without preceding numbers.

Also, JWT v2.3.1 seems to be no longer available on NuGet, and the next version 2.3.2 does have a version specified for the dependency.

However, all previous beta and alpha versions - from 2.0.0-beta2 up to 2.3.0-beta - still have the bogus dependency, which means Nuget.org does technically allow it.

In version 2.0.0-beta2, where the offending nuspec line first appeared, it had no "version" attribute at all, rather than an asterisk. This means that the asterisk was added during packing. Considering the lack of documentation for this "feature", I'm inclined to think that this is just a bug in Nuget.

Contributor

fsoikin commented Jul 2, 2017

Reading the nuspec/nuget/dotnet docs, I can't find any references to using a wildcard without preceding numbers.

Also, JWT v2.3.1 seems to be no longer available on NuGet, and the next version 2.3.2 does have a version specified for the dependency.

However, all previous beta and alpha versions - from 2.0.0-beta2 up to 2.3.0-beta - still have the bogus dependency, which means Nuget.org does technically allow it.

In version 2.0.0-beta2, where the offending nuspec line first appeared, it had no "version" attribute at all, rather than an asterisk. This means that the asterisk was added during packing. Considering the lack of documentation for this "feature", I'm inclined to think that this is just a bug in Nuget.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 2, 2017

Member

I think * should be parsed as >= 0

Member

forki commented Jul 2, 2017

I think * should be parsed as >= 0

@fsoikin

This comment has been minimized.

Show comment
Hide comment
@fsoikin

fsoikin Jul 3, 2017

Contributor

@forki:

  1. But your fix in 3b8047e already does that, no?

  2. Parsing * as >=0 is inconsistent with dotnet restore. When the spec is ">= 0", Paket will select the highest version, but dotnet restore will select the lowest (I have verified this empirically, just in case). This will cause different resolution of Newtonsoft.Json (and thus potentially different behavior) between Paket-based apps that reference JWT v2.3.0-beta and similar apps that do not use Paket. Is that ok?

Contributor

fsoikin commented Jul 3, 2017

@forki:

  1. But your fix in 3b8047e already does that, no?

  2. Parsing * as >=0 is inconsistent with dotnet restore. When the spec is ">= 0", Paket will select the highest version, but dotnet restore will select the lowest (I have verified this empirically, just in case). This will cause different resolution of Newtonsoft.Json (and thus potentially different behavior) between Paket-based apps that reference JWT v2.3.0-beta and similar apps that do not use Paket. Is that ok?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 3, 2017

Member

Paket had always been different in install behavior. I could write endless essays about that. When we do convert we try to do a conservative conversion and keep it as aligned as possible to nuget. But sometimes that's not really possible.

Member

forki commented Jul 3, 2017

Paket had always been different in install behavior. I could write endless essays about that. When we do convert we try to do a conservative conversion and keep it as aligned as possible to nuget. But sometimes that's not really possible.

@fsoikin

This comment has been minimized.

Show comment
Hide comment
@fsoikin

fsoikin Jul 3, 2017

Contributor

Ok, I suspected that would be the answer.

But what about the first point? Didn't your commit already make it parse as ">= 0"? Should this case be closed then?

Contributor

fsoikin commented Jul 3, 2017

Ok, I suspected that would be the answer.

But what about the first point? Didn't your commit already make it parse as ">= 0"? Should this case be closed then?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jul 3, 2017

Member

yes I think I did that

Member

forki commented Jul 3, 2017

yes I think I did that

@forki forki closed this Jul 3, 2017

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