should #r install a pre-release, instead of a unlisted and deprecated "stable" release?

[yueyinqiu]

Is your feature request related to a problem? Please describe.

I have created a nuget package (Yueyinqiu.Su.D2lTorchSharp), with some some stable releases uploaded. And then I wanted to add Microsoft.DotNet.Interactive reference, which is in preview, so I have to make the new versions to be pre-releases. Then it looks like:

But #r is not installing the newest pre-release version, even if I have unlisted and deprecated the old releases:

Describe the solution you'd like

I suppose that #r should act as if the unlist packages does not exist at all, unless it is installed as a reference of other packages. Or perhaps we could have some options to control this behavior.

By the way, perhaps it should have some warnings when installing a deprecated package.

Describe alternatives you've considered

I'm using *-*. However it means that one day when there is a stable release uploaded, I shall delete them in all my notebooks...

Hmm.. perhaps it won't bother too much. But the most important is that I believe installing a unlisted version should not be the expected behavior, since I can't do that in visual studio (The unlisted packages seems to be non existent there):

[jonsequitur]

These behaviors are from NuGet. .NET Interactive doesn't control them. This syntax will give you the latest release version:

#r "nuget: Yueyinqiu.Su.D2lTorchSharp"

This will give you the latest version including pre-release versions:

#r "nuget: Yueyinqiu.Su.D2lTorchSharp, *-*"

Another workaround might be to use a syntax like this:

#r "nuget: Yueyinqiu.Su.D2lTorchSharp, 1-*"

or:

#r "nuget: Yueyinqiu.Su.D2lTorchSharp, 1.0-*"

Once you release a stable version and increment the appropriate major or minor version, then the existing notebooks should continue to work by pulling the last release version with the specified version number.

[yueyinqiu]

So... what about checking that in .NET Interactive in advance, instead of directly calling nuget?

Hmmm... that might be much complicated. If you believe this is not planned, maybe I shall close this issue?

[jonsequitur]

The design is intended not to change how NuGet package loading works, so that once people understand it, the rules are consistent everywhere. But yes the rules can be a little confusing.

The way that this works internally is that .NET Interactive generates a project file containing something like this:

<PackageReference Include="Yueyinqiu.Su.D2lTorchSharp" Version="*-*" />

Then it runs dotnet restore and uses a custom MSBuild target to record the paths to the files in the restored package.

.NET Interactive is really not changing anything about how NuGet restore works.