Streamline convert-from-nuget to fit common defaults

Description

Not a bug, but a feature improvement. convert-from-nuget is a very useful command, but its utility is limited in the net core world because it takes a long time to convert on a brand new project. Consider the following scenario:

1. You create a brand new F# console app using dotnet new console -lang F#. This creates a nugetified F# project with no dependencies.
2. Run convert-from-nuget. This creates a paket.dependencies file and immediately runs an paket install:

source https://www.nuget.org/api/v2/

nuget FSharp.Core

• It takes 72 seconds to parse the graph for this.
• It supports all frameworks, even though realistically I only want netstandard and netcore.
• It downloads all packages into the local folder, using disk space and taking time, even though I have them all in the .nuget folder.

1. I now update the dependencies file to reflect these changes and run paket install to process the changes:

source https://www.nuget.org/api/v2/
framework: netstandard2.0, netcoreapp2.2
storage: none
nuget FSharp.Core

• This updates the lock file and GCs all the packages.
• This takes another 11 seconds (plus the time taken to update the dependencies file).

1. You’re now in a position to actually add your own dependencies. Let’s say Saturn - we modify the dependencies file to add Saturn as well.

• This takes another 77 seconds to parse the new graph.

Expected behavior

To get to point 4 above takes around 3-4 minutes and involves manually modifying the dependencies file as well as a full dependency pull. I would suggest a target of < 5 seconds for this entire process.

How?

Here are a few ideas for how we could improve this.

1. Switch the default dependencies file to include storage: none by default. generate-load-scripts works in 99% of cases in my experience and is perfectly usable with this option.
2. Generate specific TFMs, at least in the case of:

• There is a single project in the repo / folder.
• There is a single TFM specified in the project.
• The TFM specified is a netcore one.

In this case, generate a framework: tag of netstandard and netcore. 3. Consider not adding FSharp.Core by default. This will at least mean that the migration completes much more quickly. Besides, many packages use FSharp.Core anyway so it’s likely that the first F# library that you use will get it anyway. 4. Consider not running paket install automatically (although I suspect this would create other usability issues) 5. Alternatively, we can consider hosting a centralised cache of “known good” lock files for very common dependency graphs. This may be just for single packages like FSharp.Core on common TFMs. Perhaps this could in time be used across more complex graphs, since instead of calculating the FSharp.Core graph manually we could pull from the cache and then merge in memory (sounds good in theory, I have no clue if that would be feasible).

[Tarmil]

No, auto-detect actually parses *.fsproj to look for TFMs. It’s equivalent to listing the TFMs that your projects use.

[isaacabraham]

@Tarmil however doing this would preclude the possiblity of easily pre-generating a lock file. Or at least, the cache would need to be injected quite deep into Paket I would imagine.