Enhance the experience for the testing of packages in development

[anangaur]

https://twitter.com/Mpdreamz/status/965325828455321600

[nkolev92]

I guess the intent here is to use this for testing?

For example in my day-2-day flow I have some extra targets that let me add a new source and new global packages folder, so each time I have a new iteration of the package restored.

Personally, I'm not confident that "teaching" NuGet PR to work with individual nupkgs is a good idea, but there's definitely some improvements we can do here.

[nkolev92]

I updated the title a little bit.
We can come up with a better out of the box experience for this scenario.

The easy workaround here for customers facing this is to define a new global packages folder, by potentially adding a new nuget config file, in the root of the project where they are working.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="MyCoolLocalSource" value="F:\ServerCommon\artifacts" />
  </packageSources>
   <config>
        <add key="repositoryPath" value="LocalGlobalPackagesFolder" />    </config>
</configuration>

Ofc, you can always use some msbuild goo, but lots of people would be more comfortable with the above.

[anangaur]

I don't think it would solve the problem. I guess the intention is to replace the same version package in the project on every restore.

May be if we had the nuget locals all -clear for individual or set of packages then that might have helped?

[nkolev92]

Yeah, I forgot to mention it...they'll just do locals clear -globalpackagesfolder when ready for a new version.

That's the best you can do without any work and msbuild tricks.

[StingyJack]

define a new global packages folder,

HintPath's get broken by trying to use this unless you can get everyone to use the same local folder path,

The way I figured out to get around this OP issue in development was to use a powershell script to build the package I'm testing. It takes the current epoch, splits it in about half, and supplies that as the Rev and Build elements of the version number when packing. So long as I dont run the script twice within the same second, there isnt a problem with caching.

Consuming the package for testing is just setting up a local folder as source, within VS's sources and not in the nuget.config for the solution. The latest one us right on the Update tab of the NuPMUI

Yeah, I forgot to mention it...they'll just do locals clear -globalpackagesfolder when ready for a new version.

Who are these people you refer to? I only know nuget locals all -clear (or is it clear -all? that command is always weird) after having to try and fix a few problems. I suppose a package author would need to know pack and maybe push, and those are kind of obvs, but locals is not. I'm sure that more than one developer has trawled through the filesystem looking for cached packages to delete.

[nkolev92]

My comment about the usage of the global packages folder is meant for Package Reference.

The global package folder is the de facto installation directory for PR, while in Packages.Config it's merely used as another source.
The packages.config packages folder works differently as it's only used by the current project.

packages.config is fundamentally broken for the above scenario because of hint paths.

[StingyJack]

The content in packages.config cannot really be materially different from package ref. How its implemented in VS/Nuget is what is creating the incorrect hint paths, etc. Why you bothered with that file and created additional work instead of just addressing the hint pathing is still a mystery to me, but it seems no amount or delivery manner for feedback makes a lick of difference. Nevertheless, have some more...

Having a global packages folder sounds nice, but the command to clear them is not (use the "locals" to clear the "globals", no mention of "cache" in the command names).

Then again, I dont think I necessarily want a single folder with all the packages (in development and known good). If so, I sure wouldn't want to clear everything just to refresh a development package, or clear everything just to trim out a few unreleased development packages.

Defacto is not the same as default, so what you are saying is there is and will only be one global folder, and that by doing so you will again be creating additional burden for those who try to use this system to author packages.

[nkolev92]

The content in packages.config cannot really be materially different from package ref. How its implemented in VS/Nuget is what is creating the incorrect hint paths, etc.

The hint paths are a bad design, it's as simple as that. Creates a lot of management overhead and it's very error prone. That's why package.config is not a priority for the future.

If so, I sure wouldn't want to clear everything just to refresh a development package, or clear everything just to trim out a few unreleased development packages.

That's what this issue is for.
Improving that workflow.

Defacto is not the same as default, so what you are saying is there is and will only be one global folder,

That's exactly how Package Reference works. You can call it default if you will.
There's always one global packages folder, that's a common thing among package managers nowadays.
It minimizes the need for deduplication. The build system then knows how to copy those files into the output folders when needed.

and that by doing so you will again be creating additional burden for those who try to use this system > to author packages.

In the packages.config case, the global packages folder is still used, rather as a priority source.
Meaning if I'm developing PackageA 2.0.0, and do a restore, it'll extract it to the global packages folder and copy it to the packages folder of the project that I'm testing.
Then I'd need to delete the packages folder and run another restore, but that'd pick up the extracted package from the global packages folder.
Basically packages.config = 2 actions required, package reference = 1 action required, so it's not an additional burden.

[StingyJack]

Hint paths are part of the project system and not of nuget or packages.config. The PackageRef implementation could have used them too, and instead of fixing the packageCfg implementation to not use them, you all decided to do what is generally the most expensive and disruptive choice in software -
a total rewrite.

Npm can use a global folder, but I'm not required to do so. I'm pretty sure Bower is the same. And the difference in word choice between "Defacto" and "Default" is important. The former means "this is what it is, there are no choices", but I think you are saying the truth is that its the latter and there is a choice to be had, and by the individual developer and not governed by a config that is checked into version control and locking everyone in.

I hope its not going to be as infuriating as the GAC is in regards to loading assemblies, where the GACced asm is loaded before one adjacent to the program's location.

PackageCfg could use a global folder, but I found it was broken due to hint path.

[nkolev92]

Hint paths are hard coded values.
Fixing it is nearly impossible. Only the VS project systems knows how to do these problem, so NuGet will never have a consistent experience when working from commandline.
There's lots of other flaws with the whole approach, merge conflicts etc.
Not to mention that moving projects from 1 location to another is impossible.
The whole concept is fundamentally flawed.

That's why in package reference, the knowledge of where exactly do dependencies come from is decoupled from the knowledge about "which" dependencies I want.

Again, packages.config uses global packages folder as an extra source.

Regarding the defacto vs default.
There's no other options in PackageReference.
Packages are "effectively" installed in the global packages folder. That's the only place where a nupkg will ever be extracted.
With the help of the project.assets.json, the build knows how to find these files and copy them around during build.