search

nunit / nunit

NUnit Framework
https://nunit.org/
MIT License
2.51k stars 728 forks source link

Deprecate the existing Chocolatey framework package #452

Closed rprouse closed 6 years ago

rprouse commented 9 years ago

Chocolatey is becoming a popular way of setting up development machines and installing software using PowerShell. People have already released NUnit 2 Chocolatey packages, https://chocolatey.org/packages/nunit, but we should be releasing official verified versions.

I am marking this low priority since NuGet is our major distribution channel, but with Chocolatey's recent successful KickStarter campaign, it is going to become even more popular.

Information on creating packages is available at https://github.com/chocolatey/chocolatey/wiki/CreatePackages

CharliePoole commented 9 years ago

Sounds good to me. In keeping with the chocolatey (and nuget) philosopy, I think it should be split into multiple pacages, possibly with dependencies. If there's a good chocolatey install for the console runner plus engine, then I'd consider dropping the equivalelnt nuget package.

CharliePoole commented 9 years ago

This should be done, but since a chocolatey install would essentially wrap our other installs, implementation should wait until we determine what other installs we are supporting.

DustinVenegas commented 9 years ago

@CharliePoole, I'm interested in this and have a few questions for the implementation.

Thanks!

CharliePoole commented 9 years ago

@DustinVenegas Bear in mind that this repository is for NUnit 3.0, which is substantially re-written from NUnit 2.x. We may even treat it as a new product for Chocolatey purposes - that's not yet decided.

I will be issuing a chocolatey package for NUnit 2.6.4, which will pretty much look like the one that already exists for 2.6.3.

For the major version, things may change. We are in general trying to get away from massive installers that install everything in favor of interrelated smaller packages -- pretty much in the style of apt packaging..

In answer to your questions:

I am still pretty much in the dark about chocolatey. I hope to get to know it by working on the 2.6.4 package. I have heard that it supports meta-packages - packages that simply pull in others. Does it also support virtual packages - i.e. dependencies that can be satisfied by one or more real packages?

DustinVenegas commented 9 years ago

@CharliePoole,

The NUnit package should become the virtual package. Portable packages are Chocolatey nomenclature for "bin deploy". Install packages denote a Windows installer under the covers.

I do not recommend creating a separate NUnit3 package in Chocolatey. If we did then users would depend on the "nunit" package to install the 2x series and "nunit3" to install the latest version. Users can easily and reliably depend on the semver.

If I want to install...

CharliePoole commented 9 years ago

Right. But that only works if the underlying packages being installed follow the same structure as NUnit 2.x. If, for example, there is no big do-it-all Windows installer to reference, then there can't be such a package in Chocolatey.

Since NUnit 3.0 is not fully backward-compatible with NUnit 2.x, by design, it seems like a bad idea for users to get an automatic upgrade at any point.

That said, it's probaly better to wait to discuss this until 1) We know what the underlying package structure of NUnit 3.0 will be, and 2) I actually know more about Chocolatey. :-)

Essentially, that's why this is in the 3.0 milestone, which means we don't plan to do it till after all the betas are finished.

ChrisMaddock commented 8 years ago

Do we still want to do this?

It looks like the current packages are gathered automatically by scraping nunit.org. (Which incidentally, has broke for 3.4.1, did the nunit.org/download page always link to GitHub, or is that new?) Seems like something that we could avoid if we had it as a feed.

There's currently 3 nunit packages, with ~15,000 downloads, so it's getting a fair amount of use. I wouldn't mind having a look at it, after the installer is in a new repository?

CharliePoole commented 8 years ago

@ChrisMaddock Chocolatey uses an automated process to produce what it produces. I had never realized it was scraping our website though. That sounds like an approach that could easily break. Since I just made changes to the download page, I'm not surprised it broke.

I tried to work out something with the folks doing the chocolatey packaging and in fact they added me as one of the packagers. I felt that would give us some influence at least and that we might ultimately do the chocolatey packaging ourselves. They continue to package the msi, however, even though I told them at the time that we were going to get rid of it.

It's pretty normal in the open source linux world that packagers do what they believe their users want and upstream developers don't have much say about it. It seemed like the chocolatey folks are importing that structure to Windows as well.

However, it could be that I gave up on them too easily. You're welcome to assign this issue to yourself and give it a try.

PS: I only know of two packages, the V2 and V3 msis. What's the third?

ChrisMaddock commented 8 years ago

I only know of two packages, the V2 and V3 msis. What's the third?

They currently package the msi, the .zip (Which we'll no longer have), and a "meta-package", which points to the msi under the name "NUnit" (as opposed to "NUnit (install)"). These are all available for versions 2.6.4 and 3.X.

I think we should continue both of these - I'm assuming, if not msi, we'll continue to have some sort of installer. The zip could just contain the engine/console/addins, i.e. what would be installed by the installer? Meaning NuGet remains the main distribution for the framework.

CharliePoole commented 8 years ago

OK, that makes sense. Note that we aren't stopping the zip, although it's contents will change.

My view is that we don't package anything special for chocolatey. We just figure out what combos of things our users need and create those packages. We just need to push back a little when users merely want a certain package type purely out of habit. I think combined framework and runner is one of those things except for the case of a "getting started with nunit" package, should we eventually do one.

The important thing for us, I believe, is to recognize the same thing that the chocolatey folks have recognized: packaging bundles is different from developing the software in the first place and is best done separately.

jcansdale commented 8 years ago

Isn't Chocolatey based in NuGet? Wouldn't it make sense to use one of the NUnit NuGet packages rather than a script? Disclaimer, I know virtually nothing about Chocolatey. :wink:

CharliePoole commented 8 years ago

It's all quite academic if we can't have any influence on what the chocolatey folks do.

ChrisMaddock commented 8 years ago

I believe chocolatey packages need to be packaged differently as they have different independent installation scripts. (I presume the default generated ones would do all we need, will have to check.) But they do use nuspec files, so it may be possible to share that, with some added extras for chocolatey.

Good point though, it would be nice if the contents of the portable version reflected NUnit.Runners NuGet package. Less to keep track of!

DustinVenegas commented 8 years ago

Some small notes since this has been over a year.

Both the portable (bin install) and full NUnit packages can be packaged for Chocolatey with the .zip/.msi included in the package or a permanent URL to download the package. In other projects I have used the Github release URL to dynamically download the appropriate package.

To @CharliePoole, if the nunit package is a metapackage then note Chocolatey doesn't automatically update anything. Users have to specify they want to blindly update packages to the latest version, or create a packages.config file and ensure specific versions of the package are installed.

I still recommend an NUnit metapackage so other packages can depend on any version of NUnit installed and then having specific packages for the individual versions. This is no different than using apt-get/brew install nodejs and it installs the latest version versus specifying a specific version you need.

CharliePoole commented 8 years ago

@DustinVenegas Not sure what you mean by the portable versus full packages. We have a portable framework build, but it is not packaged separately from the other builds. Only silverlight and compact framework come in separate packages. I definitely agree tht they should be using the github url to get the packages, not scraping the website pages, which can always change. However, I say "they" because it's not in our control.

I agree that a meta-package is the way to go, but again it's slightly out of our control since we aren't doing the chocolatey packaging. I think of our nuget NUnit.Console package as an approximation of a metapackage, within the limits of what nuget supports, but it's nothing like the power of a metapackage in the world of apt-get.

Is there a way we could start doing a chocolatey package ourselves, independent of the folks at chocolatey.org?

ChrisMaddock commented 8 years ago

@CharliePoole - Chocolatey refers to packages without an installer as portable - unrelated to .NET portable. The current nunit.portable package is just the .zip NUnit releases, as opposed to nunit.install which is the msi.

Chocolatey.org generally seems keen for software vendors to maintain their own packages, so I'd be hopeful we could work something out to take over the existing packages - although from your experience it sounds like it may not be as smooth as expected. I was planning to get in touch after #1716 is finalised, and now probably after I've been away - however, if anyone wants to do this sooner, they're welcome to take over. :smile:

ChrisMaddock commented 8 years ago

I still recommend an NUnit metapackage so other packages can depend on any version of NUnit

@DustinVenegas - Can you clarify what you mean here? The link below is the current NUnit meta-package (by the chocolatey guys) - it looks to me like that just passes through a specific version of the installer package? At what point does the metapackage allow you to "depend on any version" that nunit.install doesn't?

https://github.com/dtgm/chocolatey-packages/blob/master/automatic/nunit/nunit.nuspec

I make no claims to be a chocolatey expert, either!

DustinVenegas commented 8 years ago

@CharliePool, You're listed on the Chocolatey NUnit package. @dtgm is quite responsible and will likely accept a PR or we can ask him to stop automatic packages all together and it could be included in the release process. I did something similar for Carnac. The "Contact Site Admins" or Gitter channel are both good places to ask as well.

@ChrisMaddock , You are correct that metapackages don't allow anything special right now. Chocolatey is still finalizing "virtual packages", which would allow nunit.portable or nunit.install to fulfill the nunit dependency. For the time being creating what Chocolatey calls metapackages is the correct methodology to follow in preparation for that.

To meet @CharliePoole wanting to phase out the installer I recommend that we either submit a PR to @dtgm or take over the process ourselves. The metapackage, nunit, should contain releases for v2 and v3 and should depend on the nunit.portable package of the same version. End consumers get to easily choco install nunit --version 2.x.x for build servers/dev machines. Other packages get to depend on <dependency name="nunit" version="3.x.x" /> which will be fulfilled by either the installer or portable packages in the future.

CharliePoole commented 8 years ago

@DustinVenegas Yes... I became listed back when I was hoping to be able to take this over... the Chocolatey folks were very welcoming in that way and added my name. They just didn't want to take my advice, so having my name there is purely honorific. :-)

To be clear, I took no offense. This is a pretty common sort of disagreement between packagers and upstream developers in the linux world, so it's no surprise to see it here.

If we could offer alternative packages for Chocolatey, then I think it would be time to take up the discussion again. Somebody with an interest in creating such packages needs to pick up this issue.

One point... Your suggestion to make a metapackage that covers both NUnit 2 and 3 seems incorrect. I can't think of any requirement that could be met by either NUnit V2 or NUnit V3. They are incompatible products at the interface level. Can you give an example of something that might depend on such a metapackage?

DustinVenegas commented 8 years ago

@CharliePoole,

The Chocolatey developers have been very welcoming. If you want to take full control of the packaging then reaching out to @ferventcoder on Gitter, or the Contact Admins link should be the easiest.

Now, regarding the metapackage. As a Chocolatey end-user, I expect choco install package to install the very latest default version of the package. If I'm creating automation scripts for a build server then I might take a dependency on nunit-2.6.* which would install the latest 2.6 release. If I were creating a package I might depend on anything nunit-3.2.* or a more specific version.

The metapackage looks and functions exactly the same as the (Nuget package)[https://www.nuget.org/packages/NUnit/] where the semver is enough to denote breaking changes. They're just a way for nunit.portable v2.0.2 or nunit.install v2.0.2 to meet the nunit v2.0.2 requirement. It also allows me to install multiple different versions of the same package concurrently.

Since you're trying to get rid of the installer it might be sufficient to just publish the portable (bin) installs to the nunit package. That said, all my automation currently depends on nunit 3.2.1, which defaults to the installer. That might be interesting.

CharliePoole commented 8 years ago

@DustinVenegas As I said, they were welcoming to me as well. We just couldn't agree on what they wanted to package.

I've already had extensive contact with the very folks you are suggesting I talk to. They have made it clear that they don't want to change what they are doing. That's why I asked you if it's possible to create packages in chocolatey form, without their involvement.

I think you and I will just have to agree to disagree on the ease of working with the chocolatey guys.

Regarding the metapackage, I suppose that's reasonable, depending on what you mean by "taking a dependency on nunit." There is only one assembly name in common between v2 and v3.

ferventcoder commented 8 years ago

They just didn't want to take my advice, so having my name there is purely honorific. :-)

@CharliePoole actually we added you in hopes that you would start releasing packages. Here is the original conversation for others - https://chocolatey.org/packages/nunit#comment-1840892100. It was about a year ago. In that time there hasn't been much movement on the part of the NUnit folks in actually releasing packages or asking @dtgm to stop releasing versions using auto packaging so that you could (at least not that I'm aware of).

It's completely fine if you want to move forward with releasing packages on the community repository and we are extremely welcoming to that. However in understanding the differences between NuGet and Chocolatey, you may be overthinking things a bit. You can install NUnit.Runners as a Chocolatey package now - choco install nunit.runners --source https://www.nuget.org/api/v2/. While Chocolatey has a number more features in how it can gather binaries, it's still as simple as having the runtime binaries in the package itself. Typically folks that are not the software vendors do not have distribution rights to the software and must download it from a remote location.

ferventcoder commented 8 years ago

Output of that command by the way: image

ferventcoder commented 8 years ago

They have made it clear that they don't want to change what they are doing. That's why I asked you if it's possible to create packages in chocolatey form, without their involvement.

@CharliePoole I'm not sure about saying the current packagers "made it clear they don't want to change." I'm not sure if it's a miscommunication or misunderstanding of what was communicated, I saw a healthy dialogue about how it was currently being done, with questions about how you would see it approached for v3 - https://chocolatey.org/packages/nunit#comment-2120088484.

In regards to 3.0, you will want to change the name as registered in the registry to something different than 2.x series. Otherwise 3.0 should release under the same package name or conflicts will arise during install/uninstall as no two packages should share a common registry name. If someone wants to install an older version of nunit, they can always specify '-version 2.6.4' and 'choco pin' it.

I read this as suggestions to how you would likely go about things for releasing v3 as a separate package (as that is what you had indicated what you wanted to do in comments prior to this one) or letting v3 happen with the current "nunit" package and what would happen if no decision was made by you.

I also only have that conversation to go on, so I don't know if there was other communication from the current maintainers where it was later made clear that those maintainers don't want to see things change. Please let me know?

ChrisMaddock commented 8 years ago

Just to note, I've unassigned myself as I'm away for a while, and it looks like this is starting to move. Hope something can be worked out! :smile:

CharliePoole commented 8 years ago

@ChrisMaddock I'm actually marking this as blocked. The reason is that I've refreshed my memory from the discussion of a year ago and I realized that Chocolatey installs are always based on our installs. It seems to me that we should not proliferate the formats of our packages until we have firmly decided on what will be packaged and released.

That decision about package granularity has been up in the air since the 3.0 release and we just started to make a number of big changes with the split of framework from console/engine. I think we need to have a list of what packages we are releasing before we can decide which of those packages should be on chocolatey. In fact, the discussion from a year ago was primarily about not wanting a chocolatey release for a package we planned to discontinue and in fact just have discontinued. I'll comment separately on that.

ferventcoder commented 8 years ago

I do think that @DustinVenegas is looking at the approach of a piece of software == one package, where versions are handled as a concern of the package. Packaging is not a "one size fits all approach", as software comes in all shapes and sizes and allows for different approaches.

In the cases of software where you can have multiple versions installed at the same time, like .NET Framework 2.x versus .NET Framework 4.x, or with Ruby across multiple versions, we see multiple package names for those items. If NUnit v3 exists on a machine at the same time as NUnit v2 (or even multiple versions of each), you can have multiple approaches to packaging, where you either have someone use side by side installs for multiple versions of the same package id, or you use different package names. It's really hard to say whether breaking changes constitute using different package names.

Puppet and Puppet-Agent Packages - same software, different packages

Here's a case for consideration:

Puppet versus Puppet-Agent. Or the consideration of Puppet up to and including v3 and Puppet at 4.x+. The Puppet team decided to make new packages for Puppet-Agent (v4+) as they moved to an omnibus approach (bundling ruby and all tools into the package). While this was already being done for Puppet on Windows, we wanted to maintain parity with package names across all OS platforms, thus Chocolatey followed suit with what was done for the other package managers.

Ruby - same package for all versions, but also a package for each major

Another case for consideration:

The ruby package currently bundles everything together. We've thought about ALSO creating a ruby package per major version (1.9.x, 2.0.0, 2.1.x, 2.3.x, etc) that allows folks more choice when it comes to installing Ruby. This is also more on par with the way packaging is done for Ruby on other OS platforms.

Either of these (or something else) could be a consideration for what you guys can do. :)

You Have Options

I guess what I'm trying to say is you have options. When folks are explaining the status quo, or even when a single person is telling you how you should do things (even if it is me), I'd ask that you don't take that as someone making it clear that the Chocolatey community does not want to change. Things are fluid and fast with the Chocolatey community and you likely see changes faster than you might see with other package managers.

CharliePoole commented 8 years ago

@ferventcoder Hi Rob! I guess you "heard" your name. :-)

Since my last post, I reviewed all the discussions, which were in about three different places. Looking at them with today's eyes, I realized a few things...

  1. The folks I was talking to are not all "chocolatey guys." Some of them are actually community contributors. This wasn't clear to me at the time. In particular I was under the impression that the fellow with 900-odd packages released automatically was part of the chocolatey project, so I attributed his desire to keep doing it to chocolatey. Somehow, reading again it just clicked... chocolatey enables community folks to package releases for software of which they are not the author! That's probably obvious from your point of view, but I didn't get it.
  2. I can't recall if it's in the public discussion or a separate email, but in communicating with the maintainer I asked if he intended to keep releasing the automatic NUnit build for NUnit 3, which I prefered to take over. He said he did although he invited me to submit PRs to his personal repo. That kind of closed the issue for me. In part it may have seemed final because I was viewing him as part of the chocolatey infrastructure at the time. But mainly I felt he had a right to release his own packages of NUnit within the terms of our license, whether we liked it or not.
  3. We have known since day 1 of NUnit 3 that the days of the "master" nunit msi were numbered. We were keeping it around for compatibility and, frankly, we have kept it around too long already. It's gone now. There will be an msi for the next version of NUnit, but it won't include the framework. I don't think this is a great loss for chocolatey users, although it will have to be explained. Since the framework is a library, I think it's better handled on a project by project basis through nuget.
  4. At the time, and I believe continuing through the present, the community site contained only one package for NUnit, distinguishing them through releases. As you know, we made the decision to treat NUnit 3 as a separate package from NUnit 2, exception only being made for the framework. Treating the two different programs as one package seems superficially convenient for users but in practice leads to all sorts of confusion when they don't work the same way. I offered to take over with a separate NUnit 3 package but that offer seemed to be turned down. Re-reading the posts and emails, I guess it was probably not understood.
  5. I want to re-emphasize that both you and the current maintainer treated me just fine in that year-old discussion. If I seemed to be ranting a bit it was at the commenter who seemed to want me to start all over again.

Bottom line... I said I wanted us to maintain the chocolatey install for NUnit 3. I asked the current maintainer if he planned to do NUnit 3 as well as NUnit 2. He said yes and I backed off to avoid a conflict.

Ironically, I was actually ready to drop this issue as part of cleanup when @ChrisMaddock and @DustinVenegas started to actively comment on it. This was an internally generated issue - no user has asked for a choco install. OTOH, I like the idea of using chocolatey for tools and dropping msis entirely, so we can keep kicking this around for a while.

Just received another comment from you... I'll reply to that separately.

CharliePoole commented 8 years ago

@ferventcoder Packages versus software...

I'm glad you see options. :-)

I think that using two versions of the same package should imply that the user gets the same overall functionality in both packages. We haven't always done that well, but I'd like us to improve.

Here's what I mean...

NUnit V2 has an msi that includes

Using this package, a user can

NUnit V3 has an msi that includes

Using this package, the user can

Having one package name but telling users they can no longer do some things with the newer version but they have some other things they can do turns out to be rather difficult.

I appreciate your comment about not paying too much mind when folks tell us how we should do things - or in this case how we should have done things. Unfortunately, I was applying that in reverse and figuring there was no way to get the packager to pay attention to my opinions. :-(

Would you agree with my earlier statement that no work should be done on this issue until we actually firm up what packages we plan to produce?

ferventcoder commented 8 years ago

Would you agree with my earlier statement that no work should be done on this issue until we actually firm up what packages we plan to produce?

I would agree with that. Hard to know your path forward without a plan. 👍

We can provide input towards that as a collaborative process, be mostly hands off and just validate all is good with what you want to do, or you can ultimately submit packages to the community and we can go from there. My recommendation is one of the first two approaches. You are going to have the best idea of what you want to do here with respect to packages.

One Dependency Requirement - Chocolatey Framework

The one currently firm thing with respect to packaging is dependencies - dependencies are application to application level, not DLL-level. A respective unit (a package) should contain all required assemblies that it needs to use. So let's say you have a package called "nunit-agent" with "nunit-agent.exe" included. If nunit-agent.exe requires nunit.dll, then nunit.dll should also be present in that package.

CharliePoole commented 8 years ago

When you say "it needs to use" I assume you mean "it needs in order to run" rather than "would probably benefit from."

As an example... if you install the nunit framework (package nunit) you can build tests with it. If you want to actually run those tests, you need some kind of a runner. That runner could be the conosole, the gui, the VS adapter or something you write yourself. I would call this a "suggestion" rather than a dependency and I wouldn't expect chocolatey to take note of it.

If you install the console/engine package (we currently plan to keep them together) it's probable that you will want some version (maybe multiple versions) of the nunit framework in order to write tests that you will run, but it isn't required. Again, I wouldn't expect chocolatey to deal with this.

In those cases, you could either be running tests written by somebody else or sending the tests elsewhere to be run - I know it's a stretch, but it's possible.

OTOH, let's say that you install the gui. The gui needs some version of the nunit engine to be on your system somewhere in order to execute. The version bundled with the console will do fine as will a separate engine package if it exists. What relationship do you want in that case?

ferventcoder commented 8 years ago

When you say "it needs to use" I assume you mean "it needs in order to run" rather than "would probably benefit from."

Yes, "in order to run" - an assembly level dependency.

OTOH, let's say that you install the gui. The gui needs some version of the nunit engine to be on your system somewhere in order to execute. The version bundled with the console will do fine as will a separate engine package if it exists. What relationship do you want in that case?

If the engine is an executable, package. If the engine is a DLL, this is where it starts to get fuzzy. Typically that means it goes into each package that needs it. It's not unheard of to see log4net in several packages.

Other considerations:

CharliePoole commented 8 years ago

The engine is a dll that can is used by a runner through an api. The api is a separate assembly and is always packaged with whatever runner needs it. The api assembly knows how to find an engine, load it and use it. Thus, the engine vaguely resembles a service (windows) or daimon (linux).

Runners generally require a minimum version of the engine. The express that need when they ask the api to load an engine. They may also bundle a local engine copy of the engine and the api can handle that as well. Further, some runners might actually reference the engine, in order to get around current limitations of the api assembly. The NUnit 3 adapter does that.

I think the dll/exe dichotomy is based on the assumption that the only way to use a dll is to reference it. So the true distinction may be between those things that are referenced and those that are not.

CharliePoole commented 8 years ago

As I think of it... it may be relevant to see if there are any Windows services installed as chocolatey packages and how they are structured. Even though this is not a windows service, it's still something that is sitting out there available for use by multiple tools.

CharliePoole commented 7 years ago

@nunit/core-team I think this belongs in the nunit-console project now. The NUnit package is just the framework libs and not a great fit for chocolatey. OTOH, nunit-console is a tool and it can be installed centrally by the users if we create a chocolatey package.

If you agree - or don't disagree in a reasonable time - I'll move this. :smile:

ChrisMaddock commented 7 years ago

@CharliePoole - agreed it doesn't belong here, would it not be a better fit implemented in nunit-distribution however, given it will potentially involve distributing both the msi and a portable runner with extension packages? Either way, it doesn't worry me too much!

CharliePoole commented 7 years ago

@ChrisMaddock If we were going to do an install package and a portable package, based respectively on the msi and the zip, that might make a bit of sense. Even so, it's not required because the chocolatey package merely references those things.

However, I'm thinking of doing a native portable package, based on our NuGet packages. The packages would only be references so it's easy to do it in the project itself. As a further rationale, I want to work on it myself, which makes more sense in the nunit-console project.

ChrisMaddock commented 7 years ago

@CharliePoole - agree it would be good if the NuGet packages can be reused. 😄 Regarding the install package, perhaps worth noting that that package has 15,000-25,000 downloads, compared only 350 for the portable package. (15-25k, as I'm not entirely sure how they stack!) Either way, I think there's definitely the demand for a install package.

My general preference when using chocolatey is to opt for the install packages which essentially just automate the running of the installer - that way, I have more confidence the software is installed exactly as it would have been previously when I was doing it by hand, and I should be able to avoid any messing around. Personally - I'd like the see the installer package retained. I can see how the portable packages could be vastly improved by more granular options, however!

charliepool commented 7 years ago

Hi Chris,

I don’t know why but I am getting all your messages sent to @charliePool - they are not meant for me, so you might want to check Github.

Charlie

Charlie Pool

0203 327 4762 / 07876 773 819 www.stowga.com 21 Dartmouth Street, London, SW1H 9BP

On 7 December 2016 at 14:49:04, Chris Maddock (notifications@github.com) wrote:

@CharliePoole https://github.com/CharliePoole - agree it would be good if the NuGet packages can be reused. 😄 Regarding the install package, perhaps worth noting that that package has 15,000-25,000 downloads, compared only 350 for the portable package. (15-25k, as I'm not entirely sure how they stack!) Either way, I think there's definitely the demand for a install package.

My general preference when using chocolatey is to opt for the install packages which essentially just automate the running of the installer - that way, I have more confidence the software is installed exactly as it would have been previously when I was doing it by hand, and I should be able to avoid any messing around. Personally - I'd like the see the installer package retained. I can however the portable packages could be vastly improved by more granular options!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nunit/nunit/issues/452#issuecomment-265466082, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvZpiyULPLMUNKYzYxRq-ErjVdvaiSCks5rFsdfgaJpZM4DQJtZ .

CharliePoole commented 7 years ago

@charliepool Seems like github or the mail server is confusing us.

I wonder if you're the same charlie.poole on gmail for whom I receive information periodically from various London shops. :smile:

charliepool commented 7 years ago

Haha - could well be me!

On 7 December 2016 at 15:23:20, CharliePoole (notifications@github.com) wrote:

@charliepool https://github.com/charliepool Seems like github or the mail server is confusing us.

I wonder if you're the same charlie.poole on gmail for whom I receive information periodically from various London shops. 😄

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nunit/nunit/issues/452#issuecomment-265475613, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvZpkMaL8QzLvgmwJSHOJ4VNJ11MOrSks5rFs9fgaJpZM4DQJtZ .

Charlie Pool

0203 327 4762 / 07876 773 819 www.stowga.com 21 Dartmouth Street, London, SW1H 9BP @ctapool https://twitter.com/ctapool @stowga https://medium.com/stowga

ChrisMaddock commented 7 years ago

Apologies Charlie and Charlie - I'll stop using the @ for the time being!

CharliePoole commented 7 years ago

@ChrisMaddock @rprouse This has been sitting for a while and is now one of two open framework issues that remain assigned to me.

I was under the impression that we had published nunit-console through chocolatey already. That's not so. I published the NUnit Project Editor as an exercise in learning how chocolatey works and was planning to move on to the console, but other things came up. In fact, there is no issue for creating a chocolatey package for the console - just this one.

There's a vast amount of discussion on this thread, so I'll summarize what we need to do...

  1. Create a Chocolatey package or packages for the console. I'll create that issue in the console repo.

  2. Somehow flag the old NUnit chocolatey package as out of date and no longer maintained. That can be controlled by this issue.

CharliePoole commented 7 years ago

The only thing left to do here is to deprecate the existing nunit package on chocolatey, which is based on a package we stopped producing after 3.4. I have filed an issue on dgtm/chocolatey-packages to cleanup there and will post a new version of the old package that deprecates its use.

CharliePoole commented 7 years ago

Blocked until we have a package to which we can refer users when this is deprecated.

ChrisMaddock commented 6 years ago

@CharliePoole - I think we've made the explicit decision not to put the framework on choco, haven't we? Can we close this issue?

CharliePoole commented 6 years ago

The meaning of this issue gradually changed to be removing or deprecating the existing chocolatey package - which we didn't write. I marked it block, because deprecating it means we should tell people what to use. I can check into this to see if it can be unblocked and completed.

I admit it's confusing when an issue changes meaning to become the reverse of what it originally said, but we will be adding a package when we deprecate the old one. 😄

ChrisMaddock commented 6 years ago

but we will be adding a package when we deprecate the old one.

Just to clarify, you mean we're planning to add a framework package to chocolatey? I thought we had since decided to have the framework only on NuGet, and just the runners on choco.

CharliePoole commented 6 years ago

There's an old package, not written by us on Chocolatey, based on the msi. It hasn't been updated for a long time, because it was created automatically, whenever we released nunit.msi. I have authority to update it and would update it with a deprecating package, which tells the users what they can now do rather than use the old one. You never want to delete an old package, just update it to remove all code and tell users not to use it. Chocolatey has a set of conventions around this.

What they can now do is get either the nunit-console or nunit-console-runner package. The blocking on the issue was waiting for those packages. I have to check to see if we are ready to point to those packages now. I think we are, but I have a slight doubt that we may be waiting for the next console release.

ChrisMaddock commented 6 years ago

Ah ok. I thought you meant you were planning a replacement framework package - which was news to me! 😆