fsprojects / Paket

A dependency manager for .NET with support for NuGet packages and Git repositories.
https://fsprojects.github.io/Paket/
MIT License
2.01k stars 520 forks source link

'Could not find an AllVersionsAPI endpoint' when using Artifactory repository #3638

Open rossng opened 5 years ago

rossng commented 5 years ago

Description

I'm experimenting with Paket for the first time. I have a small project that references a few packages on nuget.org and from a private NuGet v3 feed hosted by Artifactory 6.11.3.

Paket version: 5.216.0

Repro steps

  1. Create a small project using Paket, where the paket.dependencies is something like:
source https://privateartifactoryinstance.local/api/nuget/v3/privatefeed
source https://api.nuget.org/v3/index.json

nuget coverlet.collector 1.0.1
nuget Microsoft.NET.Test.Sdk 16.2.0
nuget MSTest.TestAdapter 1.4.0
nuget MSTest.TestFramework 1.4.0
nuget PrivatePackage 1.3.0
  1. Run paket.exe install

Expected behavior

Paket installs the packages from both the private and public NuGet feed, as available.

Actual behavior

Paket fails with the following error:

Paket failed with
-> Unable to retrieve package versions for 'Microsoft.NET.Test.Sdk'
   -- CLOSED --

   -- OPEN ----
      Microsoft.NET.Test.Sdk 16.2 (from C:\Users\Ross Gardiner\Documents\Projects\PaketInvestigation\paket.dependencies)
      PrivatePackage 1.3.0 (from C:\Users\Ross Gardiner\Documents\Projects\PaketInvestigation\paket.dependencies)
      MSTest.TestAdapter 1.4 (from C:\Users\Ross Gardiner\Documents\Projects\PaketInvestigation\paket.dependencies)
      MSTest.TestFramework 1.4 (from C:\Users\Ross Gardiner\Documents\Projects\PaketInvestigation\paket.dependencies)
      coverlet.collector 1.0.1 (from C:\Users\Ross Gardiner\Documents\Projects\PaketInvestigation\paket.dependencies)
-> could not find an AllVersionsAPI endpoint for https://privateartifactoryinstance.local/api/nuget/v3/privatefeed

Known workarounds

No known workaround.

Larusso commented 4 years ago

I have the same issue. By tinkering around to solve my other issue #3601 with the latest paket version I also now see this error.

Larusso commented 4 years ago

So I dived a little bit more into paket and what artifactory returns. Paket is looking for PackageBaseAddress resources. My artifactory instance returns this result:

{
    "version": "3.0.0",
    "resources": [{
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/query",
        "@type": "SearchQueryService",
        "comment": "Query endpoint of NuGet Search service (primary)"
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/registration/",
        "@type": "RegistrationsBaseUrl",
        "comment": "Base URL of Azure storage where NuGet package registration info is stored"
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/atlas-nuget",
        "@type": "LegacyGallery"
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/atlas-nuget",
        "@type": "LegacyGallery/2.0.0"
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/atlas-nuget",
        "@type": "PackagePublish/2.0.0"
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/query",
        "@type": "SearchQueryService/3.0.0-rc",
        "comment": "Query endpoint of NuGet Search service (primary) used by RC clients"
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/registration/",
        "@type": "RegistrationsBaseUrl/3.0.0-rc",
        "comment": "Base URL of Azure storage where NuGet package registration info is stored used by RC clients. This base URL does not include SemVer 2.0.0 packages."
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/registration/{id-lower}/index.json",
        "@type": "PackageDisplayMetadataUriTemplate/3.0.0-rc",
        "comment": "URI template used by NuGet Client to construct display metadata for Packages using ID"
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/registration/{id-lower}/{version-lower}.json",
        "@type": "PackageVersionDisplayMetadataUriTemplate/3.0.0-rc",
        "comment": "URI template used by NuGet Client to construct display metadata for Packages using ID, Version"
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/query",
        "@type": "SearchQueryService/3.0.0-beta",
        "comment": "Query endpoint of NuGet Search service (primary) used by beta clients"
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/registration/",
        "@type": "RegistrationsBaseUrl/3.0.0-beta",
        "comment": "Base URL of Azure storage where NuGet package registration info is stored used by Beta clients. This base URL does not include SemVer 2.0.0 packages."
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/registration/",
        "@type": "RegistrationsBaseUrl/3.4.0",
        "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL does not include SemVer 2.0.0 packages."
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/registration-semver2/",
        "@type": "RegistrationsBaseUrl/3.6.0",
        "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
    }, {
        "@id": "https://custom.jfrog.io/custom/api/nuget/v3/atlas-nuget/registration-semver2/",
        "@type": "RegistrationsBaseUrl/Versioned",
        "clientVersion": "4.3.0-alpha",
        "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
    }]
}

The result form the nuget gallery contains said item. https://api.nuget.org/v3/index.json Is this an issue with paket or artifactory?

Larusso commented 4 years ago

I try to ask again here. Can anyone tell me if this is a general issue with paket or artifactory?

matthid commented 4 years ago

@Larusso the answer is that you'd need to check the nuget v3 spec in order to check if this endpoint is required. From a practical standpoint it seems like paket should use a different endpoint when this one is not available. You'd need to check why we use it and see if a different endpoint can fill the gap.

Larusso commented 4 years ago

Ok I checked the code and it seems artifactory is missing a crucial Resource. We switched back to the v2 URLs but have the other issue with paket and artifactory #3601. So we opted to revert our versioning scheme back to semver1 for now. Thanks for your help.

jbaehr commented 4 years ago

While investigating the semver2 issue, #3601, I wanted to give the v3-API a try. So I landed here...

From what I see here: https://docs.microsoft.com/en-us/nuget/api/overview#resources-and-schema there is no AllVersionsAPI endpoint. Does Paket use some undocumented endpoint instead, which is not recomended?

matthid commented 4 years ago

@jbaehr I agree, it is good to have the docs now but they most likely didn't exist when we implemented the support in paket ;) So yes a PR to update it to be in line with the docs would be really appreciated ;)

Larusso commented 4 years ago

@jbaehr it seems you had more endurance with this issue. Seems you came down to the same dilemma I ended in. Can't use v2 with semver2 and v3 also doesn't work with jfrog at the moment. Thanks for the schema!

forki commented 4 years ago

@jbaehr we are NOT looking for "AllVersionsAPI". that's just our internal naming. In the document we are looking for "PackageBaseAddress" which is required according to the docs you found. So if artifactory is missing this then they are not implementing v3 fully.

forki commented 4 years ago

so thanks to @Larusso I could repro. The required field "PackageBaseAddress" is indeed not given by Artifactory. Can someone summon a guy from that company who can tell us how it's supposed to work?

sellmeadog commented 3 years ago

I just ran into this issue which is preventing my team from adopting Paket since our company's internal packages are required to be stored in Artifactory.

I am experiencing the exact problems described in this thread: Artifactory (still) does not provide "PackageBaseAddress" in the v3 response and Paket has apparently not found a workaround to implement.

Larusso commented 3 years ago

@sellmeadog ah well is it again over a year ago. 2020 ... I had no time anymore to spend more on this issue so we moved back to use semver1 which worked for use okish. I can try to reach out to jfrog to get a support engineer or something in this thread.

Larusso commented 3 years ago

OK I just figured out that our current plan doesn' inlcude access to the support service ...

MarioVolarevic commented 2 years ago

Is there any progress on this issue, I now tried to use this example:

source https://myCompany.com/artifactory/api/nuget/v3/cached-nuget.org

nuget FAKE ~> 5.0

on the latest version of paket, but it still fails: -> could not find an AllVersionsAPI endpoint for https://myCompany.com/artifactory/api/nuget/v3/cached-nuget.org

GitClickOk commented 2 years ago

I was evaluating Paket with great hopes when I stumbled on this problem following the "Converting from Nuget" guide... If it helps, I found this open issue in jfrog JIRA ticket. Maybe someday they will take a look: https://www.jfrog.com/jira/browse/RTFACT-20469

brettfo commented 6 months ago

For the maintainers on this repo:

Several years ago I worked on the F# compiler and language service, so I have a passing understanding of Paket and its importance to the F# community and because of my current work, I wanted to pass along some information regarding this bug.

My current role has me adding improvements to the NuGet updater for dependabot, and I recently ran into a situation there where we encountered an Artifactory/JFrog NuGet feed that didn't expose the PacakgeBaseAddress API endpoint.

I worked around the situation by detecting that the PackageBaseAddress endpoint wasn't present, and then executing a couple of different network hops to get to essentially the same information, namely the .nupkg download URL.

I wrote up my findings of the initial investigation here and implemented the fix (although in Ruby, not F#) here.

Hopefully this is useful to somebody.