Master Chocolatey issue

I’m creating this issue to coordinate our adoption and use of chocolatey. Almost all the usage will center around the console runner, so it makes sense to discuss it here. See also prior discussion on issue nunit/nunit#452, including a lot of good info about use of chocolatey from @ferventcoder.

GENERAL APPROACH

1. Although it’s an over-simplification, Chocolatey is generally good for tools and their extensions, while NuGet is good for libraries referenced by user code. We will use it that way.

   • The framework will be distributed using NuGet
   • The console runner, gui (even though separate), engine and extensions will be distributed using Chocolatey.
   • The console runner, engine and extensions are also distributed using nuget and we will keep doing that so long as users want it.

2. The engine directory will contain an addins file nunit-choco-addins with a relative path to pick up all extensions installed under chocolatey. That is, the set of extensions available to a chocolatey installation of the runner will be separate from extensions installed in any other way, such as using nuget.

3. To facilitate (2) all engine extensions will use an id in the form nunit-extension-*. This is analogous to our use of NUnit.Extension.* for nuget but conforms to chocolatey naming standards.

4. Any chocolatey packages that bundle multiple extensions or other components will do so by use of dependencies, not by directly including the software. This implies that nothing can be bundled unless it already has a separate package, which seems like a good principle. I’m inclined to encourage users to install just what they need because it educates them and eliminates surprises, but I recognize that people are used to getting bundles of functionality. Chocolatey may help in encouraging unbundling, since you can install a runner and multiple extensions simply by listing their ids on the command line.

5. The code for creating packages for a single module, such as the runner or an extension, really belongs in the project that creates that module. I am currently building them in a separate project in my own id, but they should be moved to the individual projects when convenient - probably after the next release.

6. Packages that bundle a number of extensions with a particular executable should be associated with the executable project. Packages - if any - that bundle multiple executables from different repositories should probably be kept separate.

STEPS NEEDED

1. Create package for the console runner

2. Create packages for each extension

3. If we want a combined package with common extensions, create that.

4. Deprecate the old nunit package (framework+consolerunner+extensions) in favor of (3) or (1).

5. Create a similar set of packages for the GUI.

STATUS

(1) and (2) are ready to test

@nunit/core-team @nunit/engine-team @ferventcoder Your comments are solicited and anxiously awaited! 😸

[CharliePoole]

Hey @ferventcoder ! Thanks for the info. That’s a great feature, although we will never again make a mistake that requires re-releasing a package. 😉

[CharliePoole]

All extensions except for teamcity have now been updated and re-released.