Deprecate the existing Chocolatey framework package #452
Comments
|
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. |
|
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. |
|
@CharliePoole, I'm interested in this and have a few questions for the implementation.
Thanks! |
|
@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? |
|
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...
|
|
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
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. |
|
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? |
|
@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 if I could make a recommendation... If you create an nunit account, and share the credentials within the Team using a password manager, that makes it much easier to maintain the packages going forward, rather than tying it to one individual. That is what we do with the Cake package, as an example: https://chocolatey.org/packages/cake.portable Although we, the Cake Team members, are all a maintainer of the package, it is the main cake-build account that pushes all the new package versions. Chocolatey doesn't have the same organisation concept that NuGet recently released, but what I have suggested above is a close fit for now. |
|
Thanks Gary - that sounds like closer to where we want to be in the long run! @nunit/framework-team & @CharliePoole - anyone have any objections to Gary's suggestion above? I'm happy to do the legwork to make it happen on this one. 😄 |
|
@ChrisMaddock feel free to reach out if there is anything that you need me to help with. |
|
@ChrisMaddock Creating an nunit account for use with chocolatey could be a good direction to go. We got trusted package status because the package maintainer and copyright holder were the same person, but that's not really scaleable. Once it's set up, we should probably use it for all our packages. However, adding nunit to this particular package isn't necessary because it's not a package we release any more. We're just trying to tie up a loose end. @gep13 This issue has been around a long time, so in case it's confusing, the summary is that it started out as an issue to add chocolatey packages. That work has all been done, mostly by me. In 2017, I changed the name of this issue to the one thing that was left to do, deprecating the existing automatically generated package. Probably, it would have been clearer if I just closed this issue and wrote a new one! TL;DR The automatically generated nunit package should no longer be generated at all. The combination of modules in that package no longer exists and has been replaced by other package names. The NUnit project is already producing chocolatey versions of those packages directly. I'll continue discussion of this on dtgm/chocolatey-packages#310 |
|
@CharliePoole - thanks for making the other issue. Regarding the packages we wish to keep, would you like me to take care of setting up an organisation account? It will need action from you to add it as a maintainer I believe, but I'm happy to do leg-work, as you were trying to hand this issue over! |
|
@ChrisMaddock I created the issue a long time back but I guess the project has a big backlog. I think the work of thus issue will actually get done over there. For future, I suggest finding out if the team wants an nunit account or prefers to track who is individually doing it. I'm glad to add whoever should be added and subsequently remove myself, but I think it's a team or team lead decision. WRT the four extensions, there is no team and no lead, which is why I haven't done anything. Only the teamcity extension has someone in charge of it. FWIW I considered forking some extensions at one point and may do that if one I depend on doesn't otherwise get a maintainer. |
Agreed sorry, I'm getting ahead of myself. I'll wait for @nunit/framework-team's responses. |
|
I'd prefer the organization account for flexibility. |
|
@ChrisMaddock No problem. My own preference (if it existed) would be an organization account with multiple user ids, as we have on GitHub itself. That not being available, a shared id seems like the way to go. |
|
I'm cool with an organization account too. @gep13 can you email the info to me at rob@prouse.org once it is setup? Or you can DM me on twitter @rprouse. I agree with @CharliePoole's comment that just assigning to me is moving back towards centralization. I don't want to be maintaining every aspect of the NUnit organization nor do I have the time, but I'll upload the updates while I have to 😄 |
|
@ChrisMaddock do we have a list of the Chocolatey packages we should add the organizational account as an admin for? I've stepped back from maintaining this part and don't have a full picture. I've contacted @gep13 with info on an organization account to use, we just need which packages to apply it to. |
|
I may have misunderstood but I think one of us just creates an nunit account. As o understand it, it's just a user ID and is only "organizational" in the sense that we use it as such. |
Nope - but I can make such a list next time I’m on a computer. 😊 |
|
@rprouse the package that we are talking about deprecating is not one that we maintain. It was maintained by @dtgm who added me and was created automatically whenever a new nunit.msi or zip appeared on the download page. We no longer produce that package. The reason for deprecating it is so any users of that package will know what to do. If they still use it they're stuck at 3.4, so I hope it's not many. When we shifted to what I call (I think @ferventcoder also does) native packages, we made this obsolete but never cleaned it up. The deprecated package should never have to change again and doesn't need to have nunit added as a packager it will have no content but will probably depend on the console runner package and will have a long explanatory comment you'll want to review. The nunit org ID should be added to the packages we DO maintain, not this one, since we won't be uploading it. |
|
|
|
Here's a review of the current NUnit packages on chocolatey we should aim to tidy up. I've added what I think is the best course of action for each. The following are currently under account charliepoole. To be transferred to an nunit-org account:
The following are under charliepoole and rprouse, and should be transferred to nunit-org:
The following are legacy packages currently maintained by dtgm. The top two are also maintained by charliepoole, the third isn't. All three should be deprecated in favour of NUnit 3 Console Runner 3.8.0.
The following NUnit related tools are under either charliepoole of NikolayP, and should remain as such:
The following package has been put online by an user external to all our discussions thus far. We may wish to engage with the user regards deprecating in favour of the NUnit-organisation packages in due course - but that's a separate issue!
|
|
That last one is a surprise! A bit of info about the TeamCity extension: I added Nikolay as an author of the package so he could do the updates, but kept my own name on it. By doing that, it keeps a copyright holder as one of the authors, which is what allowed our packages to be treated specially by chocolatey. I had previously wanted to add Nikolay as a holder of the copyright, since he has done most of the work for years, but his company objected. WRT removing either me or Rob from the packages, we should make sure that use of the NUnit org id will continue to give us the special handling we have been getting WRT package review before we do that. The key seemed to be having at least one name in common as an Author of the package and an Owner of the software. However, it has been a few years since I set it up and chocolatey.org may have changed practices since then. |
|
Thanks for compiling the list @ChrisMaddock, I appreciate the help. @gep13 I've created an account for the team. The username in nunit.org and the email is NUnitDeveloper@gmail.com. Can you add it as a maintainer to the packages @ChrisMaddock listed except for the last four? We'll look at getting in touch with the author of the last one separately. Also, is the last para of @CharliePoole's comment above a problem?
|
|
@rprouse @CharliePoole @ChrisMaddock I have added the new NUnit Chocolatey user to each of the packages that you requested. You can see this here: https://chocolatey.org/profiles/nunit.org Can I ask that you add the email address associated with this account to a gravatar account, and associated the NUnit Logo with it? That way, it will show up more "officially" on chocolatey.org. With regard to the special handling... Each of these packages is what we refer to as a trusted package. This means that each new package version is still subject to the automated validation and verification checks. If a new package version fails at this stage, it will be sent back to a state of "Waiting for maintainer to take corrective action", meaning that it is on one of your team to fix the package, and push an updated version. Since it is a trusted package, it won't need to wait on a human moderator coming along to approve a package, which means that it much quicker to go through the moderation process. So, long story short... Nothing has changed here with adding this new maintainer to the package. Each of these packages are still trusted. |
|
@rprouse @CharliePoole @ChrisMaddock I have just walked the following packages:
Through the deprecation process: https://chocolatey.org/docs/how-to-deprecate-a-chocolatey-package I have also removed all the maintainers that were on those packages. Please let me know if you have any remaining questions, or if there is anything else that you need me to take of. |
|
@gep13 The deprecated packaegs look right to me. Thanks! |
|
Brilliant, thanks @gep13! I’ll try and have a look at gravatar tomorrow. 😊 |
|
So!
With that, I think this issue can be closed! 😄 Hooray!
@CharliePoole @rprouse - @gep13 has confirmed the package review process remains as is. I'll leave you to make the decision as to whether to remove your personal accounts or not - I didn't feel any particular need to do that forcibly! 😄 |
|
Just as an example, this is what we do on Cake:
https://chocolatey.org/packages/cake.portable The |
|
Thanks @gep13. I guess that's one for us to think about how we want to do that organisationally. Traditionally, everything's been released under Charlie Poole's name. We've now moved away from that to a more decentralised organisation - so things like this haven't really come up much. Always been a fan of Cake shouting about it's contributors at every opportunity (e.g. release announcements). We should do more of that! 😄 |
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
The text was updated successfully, but these errors were encountered: