Skip to content
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.

Sign up for GitHub

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

Jump to bottom

When restoring packages, Paket seems to ignore NugetFallback folder #3662

Closed
rfrerebe opened this issue Sep 23, 2019 · 2 comments
Closed

When restoring packages, Paket seems to ignore NugetFallback folder #3662

rfrerebe opened this issue Sep 23, 2019 · 2 comments

Comments

@rfrerebe
Copy link

Description

In .NET Core, most (if not all) Systems nuget packages are stored in

  • %PROGRAMFILES%\dotnet\sdk\NuGetFallbackFolder on Windows
  • /usr/share/dotnet/sdk/NuGetFallbackFolder on Linux

Repro steps

  1. Install docker if needed
  2. Start dotnet container with shell access from host
docker run -it --rm mcr.microsoft.com/dotnet/core/sdk:2.2 bash
  1. Install paket inside Docker container
dotnet tool install paket -g
export PATH="$PATH:/root/.dotnet/tools"
  1. Create a sample project without paket
mkdir /app-without-paket
cd  /app-without-paket
dotnet new mvc -lang F#

dotnet restore is very fast

  1. Create a sample project with paket
mkdir /app-with-paket
cd  /app-with-paket
dotnet new mvc -lang F#
paket convert-from-nuget

paket is very slow because everything is downloaded.

Expected behavior

I expect paket to behave as nuget and use local NugetFallbackFolder instead of downloading eveything from nuget.org

Actual behavior

Paket downloads eveything from the internet

Known workarounds

None

Details on this issues

An existing PR already tried to solve this problem : #3242
but it seems that it starts with an invalid path
https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/Dependencies/NuGetCache.fs#L336

executing the same function in dotnet fsi inside a docker container

> tryFindFileOnPath "dotnet";;
val it : string option = Some "/usr/bin/dotnet"

gives /usr/bin/dotnet
while expected path starts with /usr/share/dotnet

I am proposing a PR with both path included by default

  • %PROGRAMFILES%\dotnet\sdk\NuGetFallbackFolder on Windows
  • /usr/share/dotnet/sdk/NuGetFallbackFolder on Linux
@rfrerebe rfrerebe mentioned this issue Sep 23, 2019
Merged
@rfrerebe
Copy link
Author

rfrerebe commented Sep 23, 2019 •
edited
Loading

With a local build on my machine of paket

cd .\src\Paket.preview3
dotnet publish -c Release -r linux-x64 
cd ..\..
xcopy .\src\Paket.preview3\bin\Release\netcoreapp2.1\linux-x64\publish .\bin

I am able to execute my version of paket in docker

docker run -it --rm -v D:\DEV\Paket\bin:/my-paket mcr.microsoft.com/dotnet/core/sdk:2.2 bash

Then inside docker, I can test with my fix

rm -Rf /root/.nuget
mkdir /app-with-paket-fix
cd /app-with-paket-fix
dotnet new mvc -lang F#
/my-paket/paket convert-from-nuget

Performance:

  • Resolver: 1 minute, 9 seconds (1 runs)
    • Runtime: 2 seconds
    • Blocked (retrieving package details): 57 seconds (121 times)
    • Blocked (retrieving package versions): 9 seconds (13 times)
    • Not Blocked (retrieving package details): 110 times
    • Not Blocked (retrieving package versions): 218 times
  • Disk IO: 11 seconds
  • Average Download Time: 669 milliseconds
  • Number of downloads: 82
  • Average Request Time: 161 milliseconds
  • Number of Requests: 697
  • Runtime: 2 minutes, 18 seconds

Testing without the fix :

rm -Rf /root/.nuget
mkdir /app-without-paket-fix
dotnet tool install paket -g
export PATH="$PATH:/root/.dotnet/tools"
cd /app-without-paket-fix
dotnet new mvc -lang F#
paket convert-from-nuget

Performance:

  • Resolver: 1 minute, 10 seconds (1 runs)
    • Runtime: 2 seconds
    • Blocked (retrieving package details): 58 seconds (108 times)
    • Blocked (retrieving package versions): 10 seconds (14 times)
    • Not Blocked (retrieving package details): 123 times
    • Not Blocked (retrieving package versions): 217 times
  • Disk IO: 7 seconds
  • Average Download Time: 398 milliseconds
  • Number of downloads: 231
  • Average Request Time: 174 milliseconds
  • Number of Requests: 862
  • Runtime: 2 minutes, 48 seconds

So we found 143 packages locally and did save some download time

@forki
Copy link
Member

forki commented Sep 24, 2019

I'm open for PRs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@forki @rfrerebe