#3127 storage symlink feature #3128
Conversation
|
@forki I don't know why there was an error on the Travis ci build with mono. Could you help me ? The metaproj error is a little bit weird for me. Thanks! |
Paket.preview3.sln
Outdated
| Microsoft Visual Studio Solution File, Format Version 12.00 | ||
| # Visual Studio 15 | ||
| VisualStudioVersion = 15.0.26730.0 | ||
| MinimumVisualStudioVersion = 10.0.40219.1 | ||
| Project("{6EC3EE1D-3C4E-46DD-8F32-0CC8E7565705}") = "Paket.Core", "src/Paket.Core.preview3/Paket.Core.fsproj", "{779DA2DD-CEA0-4EC4-9DBD-2CF29C2269EA}" | ||
| Project("{6EC3EE1D-3C4E-46DD-8F32-0CC8E7565705}") = "Paket.Core", "src\Paket.Core.preview3\Paket.Core.fsproj", "{779DA2DD-CEA0-4EC4-9DBD-2CF29C2269EA}" |
There was a problem hiding this comment.
change \ back to / and travis will likely work again...
src/Paket.Core/Dependencies/NuGet.fs
Outdated
| if not isLocalOverride then | ||
|
|
||
| match isLocalOverride, configResolved with | ||
| | true, ResolvedPackagesFolder.NoPackagesFolder -> return failwithf "paket.local in combination with storage:none is not supported" |
There was a problem hiding this comment.
Maybe we add to that message "use storage: symlink instead" ?
| @@ -111,7 111,7 @@ let ExtractPackage(alternativeProjectRoot, root, groupName, sources, caches, for | |||
| | LocalNuGet(path,_) as source -> | |||
| return! extractPackage caches package alternativeProjectRoot root localOverride source groupName v includeVersionInPath downloadLicense force | |||
| } | |||
|
|
|||
| @@ -203,14 203,13 @@ module RuntimeGraph = | |||
|
|
|||
| open System.IO | |||
| /// Downloads the given package into the nuget cache and read its runtime.json. | |||
| let getRuntimeGraphFromNugetCache root groupName (package:ResolvedPackage) = | |||
| let config = PackagesFolderGroupConfig.NoPackagesFolder | |||
| let getRuntimeGraphFromNugetCache root configO groupName (package:ResolvedPackage) = | |||
|
One could argue about starting external processes, but we already do that on other places as well. |
cboudereau
force-pushed
the
master
branch
2 times, most recently
from
3c36f10
to
d7ed41b
Compare
|
Yeah about external process I agree but dotnet core API are not yet ready due to case clash between claimed and FileInfo/DirectoryInfo (https://github.com/dotnet/corefx/issues/25569). So I reuse the external tools to preserve OS dependent behavior. |
cboudereau
changed the title
|
@matthid I have fixed the last failing test. There is some well known tests failing on AppVeyor (as I understand according to previous merged). Is it ok for you ? Thanks in advance for your help! I appreciated it |
|
Hello @matthid, do you think that the checks are done (even if there is well known failing tests ? I am currently investigating why those tests failed) |
|
@forki is this ready? is the test failure related? |
|
Here is the diagnostic : " Lowercase package names in package cache: old csproj, packages folder enabled" is failing due to FSharp.Core binding redirects (4.4.1 -> 4.4.3) of the FakeLib.dll logger. By disabling logger the test works fine (Fake.MSBuildHelper.MSBuildLoggers <- [] //There is a fsharp.core binding redirect issue on the FakeLib.dll logger) "#2335 should install deps from different groups when using conditions" : this one failed due to new framework versions. "#2294 pin NETStandard.Library = 1.6.0 Strategy Workaround" : paket timeout after 7mn I am running with a timeout infinite the #2294 but test are still running for 20mn. If I compare the build tests between mine and the last merged, tests are on the same status. I am adding a new commit to fix 2 tests. |
|
I wonder if we can make that the default eventually? |
|
Probably. Let's make it opt-in for now, and make it default later when we are sure there are no problematic edge cases. |
|
I get:
|
|
Which OS/Environment ? (as I understand it is a permission issue). We are currently running it on windows without highest privilege. Same on bash ubuntu for windows. |
|
running on windows in non-admin terminal |
|
Have you checked policies around mklink : Local Policies\User Rights Assignment\Create symbolic links ?? |
|
So no default for now ;) |
|
But it is probably fine as it is. I don't think it will get any better than this. |
|
Are you sure there's not some process locking the dll ? |
|
We reproduce the problem on our CI server on a build.. checking what's happening. |
|
By configuring the local policy it works fine
…On Tue, Mar 27, 2018, 11:36 Jérémie Chassaing ***@***.***> wrote:
We reproduce the problem on our CI server on a build.. checking what's
happening.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3128 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB_rV4285nYzjeU3_B8ACelDzfUJK3rqks5tiggtgaJpZM4S0e2G>
.
|
|
@cboudereau can you please send a PR to the docs with details? also a error message that points to the docs would be nice |
|
Sure
…On Tue, Mar 27, 2018, 13:39 Steffen Forkmann ***@***.***> wrote:
@cboudereau <https://github.com/cboudereau> can you please send a PR to
the docs with details? also a error message that points to the docs would
be nice
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3128 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB_rV4w6m26x5ymvJTbCf82Rk0-_w0szks5tiiT_gaJpZM4S0e2G>
.
|
|
done #3134 |
The impl is done
I have manually tested on mono windows the behavior (paket local, restore, install and update) with and without the configuration / globally and on a specific package.
On a little project 5s before and 270ms after.
When you restore dotnet core packages and the nuget cache is full the restore phase is less a second instead of 20s.
I am building integration test.