Open aggieben opened 2 years ago
@aggieben FYI, this is the logic to find it:
maybe you could try to execute the same logic in your environment and come up with a patch for the implementation?
let nugetDirs =
let nugetDir = DirectoryInfo(Path.Combine(userProfile, ".nuget", "packages", "paket"))
if not nugetDir.Exists then
Seq.empty
else
nugetDir.GetDirectories()
|> Seq.map (fun d ->
let splits = d.Name.Split('.','-')
let numberSplits =
[|
for split in splits do
match Int32.TryParse split with
| false,_ -> Choice2Of2 split
| true, v -> Choice1Of2 v
|]
d, numberSplits)
|> Seq.sortByDescending snd
|> Seq.map fst
|> Seq.map (fun d -> Path.Combine(d.FullName, "tools"))
I think the reason it fails is that a version which has a -
will give a Choice2of2 in a list, which will put it before any other version which has only Choice1of2
in it.
It looks faulty indeed.
Yeah, that's what I found as well. I've been playing around with it in FSI for a while and honestly I'm not sure it's really worth trying to do something sophisticated like full-on semver ordering. The simplest workaround in my particular case would be to update all my dotnet tool manifests to use the latest stable paket (or at least just delete the prerelease versions that are fouling up this ordering).
One approach that would avoid this issue might be to change
Seq.sortByDescending snd
to Seq.sortByDescending (snd >> Seq.take 3)
I'll try to fix it, thanks for the report @aggieben!
Description
When I run FSI using the Dependency Manager extension for paket, it resolves a path to
paket.exe
through an older version of a dotnet CLI tool package.Repro steps
Please provide the steps required to reproduce the problem
Launch FSI with
dotnet fsi --compilertool:"D:\Users\ben\proj\mbrace\MBrace.Core\packages\fsi\FSharp.DependencyManager.Paket\lib\netstandard2.0\"
Evaluate this:
#r "packet: nuget FSharp.Data" // or any package name, this is just the one I used.
Expected behavior
The dependency manager resolves to latest available version of the paket cli tool and successfully resolves requested package.
Actual behavior
I have the following installed versions of the paket CLI tool:
Known workarounds
Please provide a description of any known workarounds.