Feature request: add to Chocolatey

[nagromc]

I think you should add the installer to Chocolatey package manager for Windows.

[chrisant996]

There doesn't seem to be very clear documentation for the end to end process of creating and publishing a package for chocolatey.

But it seems it requires:

• A nuget package, published to a nuget feed.
• A chocolatey package, referencing the nuget package, and adding various requirements and whatnot.
• Some number of actions, considerations, and requirements when creating and maintaining packages.
• A variety of manual actions, every time a new release is published.
• Many hours invested to learn, experiment, test, and maintain packages.

It seems a bit expensive for a maintainer, and that's a fairly big investment of my personal time.

In contrast, for scoop, someone made a .json file, and now scoop offers clink. And the clink,json package definition is automatically updated when new versions of clink are released. Very inexpensive, with no special actions or requirements on a maintainer.

Maybe someone else would be interested in creating a chocolatey package for clink?

[bruceoberg]

i may look into this. the big problem is that clink 0.4.9 is already uploaded and approved in the chocolatey community repo. so an unsuspecting choco user (e.g. me 48 hours ago) can blindly install clink and accidentally get the old mridgers version.

the clink package in the chocolatey community repo looks like it was built (in 2018) via nuget scripts here: https://github.com/doggy8088/clink-chocolatey

[bruceoberg]

results of more research:

i believe @doggy8088's chocolatey setup was made following this tutorial. it's not ideal because things like the version and release notes are hardcoded into the .nuspec file and thus need to be edited manually for each new release.

this post about dotnetpretty is about using myget to automate the publishing process.

this post about powergist is similar, but uses appveyor to do the building and publishing.

it appears that the perforce tools are published to chocolately using appveyor and a manually edited .nuspec file via this project.

[bruceoberg]

@chrisant996, if i may ask, what's your current process for publishing new clink releases in this folder? are you compiling those builds yourself or using a service like appveyor? i believe the chocolatey publishing process could be hooked into whatever mechanism you use to make your releases.

[chrisant996]

@bruceoberg This is a bunch of very helpful info, thank you!

I build and deploy manually (personal preference), though it's mostly automated via local scripts. I am happy to add a step to build a .nuspec programmatically and run publishing steps, I just need to know how. The @doggy8088 stuff you found looks like it covers most/all of what's needed.

In particular, it looks as though maybe chocolatey.org has its own nuget feed server? That would simplify things.

I wonder whether I can "take over" the existing chocolatey clink package.

[bruceoberg]

i'm still trying to figure out the best practices and/or state of the art for easily making/publishing chocolatey packages.

the most coherent example i can find is within the openhv project. they have a packaging directory and buried in there are all their chocolatey related files. in addition, they have a github workflow which does all the chocolatey packaging and pushing. you can see in this workflow how they patch various files to insert the version number etc.

in contrast, the asciidoctorj project has a directory with chocolatey files but the readme outlines the manual process for packaging/pushing. no workflow actions are involved, and the versioning is manual via submitting changes.

another reference point is that powergist post i mentioned. if you look at the project's github page, you'll see the chocolatey related files at the top level and no workflow/instructions anywhere. this makes sense as i believe appveyor is doing all the work for them. that said, if you look at the powergist msvs solution file, you'll see some nuget stuff going on. so it's possible that visual studio could be doing some of the packaging work.

i'm posting all this mostly as a record of my searching. one of these days i'll clone clink and try some experiments there.

as for taking over the package, i'm not convinced the chocolatey folks are all that careful about ownership. for example, the official perforce package comes from this project, which doesn't seem to be related to any official perforce company account. updates are being made manually, and there is a separate and parallel project for p4v.

[briantho]

This feature really should be implemented. from an end user standpoint, choco is great for easy installs and easy upgrades. If choco is too much, then maybe create some sort of auto updater for clink to keep clink up to date?

[chrisant996]

This feature really should be implemented. from an end user standpoint, choco is great for easy installs and easy upgrades.

That's why it's still an open issue.

If choco is too much, then maybe create some sort of auto updater for clink to keep clink up to date?

Look in the TODO.md file in the repo root...

[chrisant996]

@briantho Also:

• Follow the discussion at https://github.com/doggy8088/clink-chocolatey/issues/1.
• See https://community.chocolatey.org/packages/clink-maintained which has a newer version, though it doesn't appear to be kept up to date.

[piotrek-szczygiel]

Hi, I own the clink-maintained package. I actually updated it about an hour ago to 1.3.8, but the chocolatey publishing process takes a lot of time for some reason.

I actually personally stopped using chocolatey, but didn't want to completely abandon the package as it gained some traction among chocolatey users.

I never made another chocolatey package, so I am actually not really a good person to ask for help on creating chocolatey packages. I only modified the original chocolatey package to use a new download link. Source can be found here: https://github.com/piotrek-szczygiel/clink-chocolatey

I am fully willing to give you any needed access to my package. If you successfully take over the original clink package I can also unlist it from chocolatey repository, as I think it is currently impossible to delete the package.

Let me know if I can help in any way.

[piotrek-szczygiel]

Also removal of autorun being the default while installing can confuse people using chocolatey, as it installs it silently and they now have to manually find the Clink in the start menu and issue the clink autorun install.

Maybe it would be preferable to add some switch to NSI installer enabling the previous behavior, so it doesn't confuse people.

[chrisant996]

Also removal of autorun being the default while installing can confuse people using chocolatey, as it installs it silently and they now have to manually find the Clink in the start menu and issue the clink autorun install.

Maybe it would be preferable to add some switch to NSI installer enabling the previous behavior, so it doesn't confuse people.

Yeah, thanks, I saw that and I'm thinking about options.

Worst case, it becomes the default again. Not my first choice, but not an unreasonable outcome, if necessary.

[chrisant996]

This is at an impasse:

doggy8088 wants to keep his "clink" chocolatey package permanently on the old v0.4.9 to avoid surprising existing downloaders with new updates, and to avoid any possibility of compatibility problems.

doggy8088 is not responding to queries about updating the package listing to be clear that it is an old version, or providing a link to the new version.

This is not worth the time and frustration to me, so I'm closing this issue. If the situation bothers chocolatey users, they'll have to contact doggy8088, as there is nothing I can do about this.