Should we enable Nuget Package Restore about chocolateygui

[chrissie1]

I hear nothing but bad thing about it.

[gep13]

Really?!? How so? I have been using it in a couple projects now, and I haven't had any problems with it.

[chrissie1]

Must have been Hadi who was complaining about it.

[tarwn]

The problem with using Package Restore is that unless you are capturing the package details with every build, there is no guarantee that any given build will have used the same packages in any two places. Duplicating a build becomes incredibly difficult, and if the restore takes place during your automated build process, then suddenly you have builds breaking that are unrelated to the commit(s) that are being tested (or worse, packaged for deployment to fail later). Having the packages committed also means you know exactly what version of XYZ component was in use with reported issue 123.

Also, TeamCity reports Rhino as missing in the .Test project.

[gep13]

Ok, I am slightly confused by this...

Isn't the packages.config responsible for indicating what version of a package is used during any particular build?

Gary

[tarwn]

Sorry, that's my mistake, disregard most of that. There's been a bunch of conversation in the last couple days about package restore in the context of also applying updates automatically and I was stuck in the wrong context.

The concerns with using package restore (out of the box, using exact version) is the build dependency it adds, the security risk that the ruby gem repo had last month, and some ongoing issues w/ packages that have scripts that break things in build environments. The build dependency is that the build depends on the nuget servers being up in order to work, but this is more of an issue for projects that build at higher frequencies. The security risk is real, but likely much higher for other projects and hopefully efforts have been ramped up on that front since the gems repo issue last month. The last one is work-aroundable, any packages that execute change scripts after download that cause breaking changes to the build targets, project files, etc can be included so that package restore still works properly for the rest.

I personally wouldn't use package restore for anything that I was deploying with high frequency, but that's more because of the nuget server dependency and potential for slowing down my builds if I had to download packages with any regularity (there is caching which should solve this, but...). For a project like this, I think the key thing would just be ensuring any packages with breaking change scripts are still committed, but that restore would work fine for the rest.

Note: there is some concern over whether package dependencies are pulled down with the specific version or not, but I haven't seen anything definitive and this was part of what kicked off the overall conversation about adding an auto-upgrade to restores. My suspicion is that dependencies are being downloaded correctly by comparing to the packages file or, if not, someone is fixing this to work properly. There's some smart people involved w/ Nuget and this seems like something they would have caught.

[tarwn]

To be clear on the build script issue: I don't think they actually run for package restore (but there's some confusion in the issues list on nuget for this and I don't really know for sure), but a number of packages have content files, alter configs, move files around, etc that mean a restore may not have the same things available that a local install has. I think this will probably get better over time as people run into issues with packages that rely on this type of thing, but for now we still have to keep our eyes out for packages that end up in a different state when installed vs restored.

[chrissie1]

For now I will say no.