Chocolatey-coreteampackages: (putty) should depend on putty.install not putty.portable

[cinderblock]

Expected Behavior

choco install putty should install via putty.install.

Current Behavior

choco install putty depends on putty.portable.

Context

The FAQ says:

Nearly 100% of the time, the package with no suffix [...] is going to ensure the *.install.

Previous discussions:

• https://chocolatey.org/packages/putty#comment-3853905911
• https://chocolatey.org/packages/putty#comment-2393754748
• https://github.com/ferventcoder/chocolatey-packages/issues/100

To be fair, one commenter wants the portable as default however, imho, they should be forced to install putty.portable.

[majkinetor]

Perhaps, but now we can't change just dependency as people want putty on path and already used it in such way in scripts, so to do this I believe putty.install will need to create shims.

I personally think this is irrelevant.

[cinderblock]

I believe putty.install also adds putty to the PATH.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[cinderblock]

I think this is still relevant. Every time I setup a new system putty.install sticks out like a sore thumb in the line of packages I install all at once.

[majkinetor]

What does that even mean ?

[cinderblock]

It's the only one that I commonly install that still requires the .install postfix:

> choco install 7zip putty.install nodejs yarn nmap wget hwmonitor

[majkinetor]

Well, in that case, we have to comply. That really looks horrific - I think I will lose my sleep over that line tonight. :)

[AdmiringWorm]

here, let me fix that for you

> choco install 7zip.install putty.install nodjs.install yarn nmap wget hwmonitor

There, now it won't feel alone :laughing:

All joking aside, a meta package should not suddenly change from a portable package to a installer one, as this would be a breaking change (most that have a default install of choco probably won't notice this though).

Now, why do I say it is a breaking change? It actually got nothing to do with the program being available on the system path.
To think about why this would be a breaking change, we need to think about what the difference between an .installer and a .portable package is.

A portable package makes a program available to the the user without actually installing the program (ie: it won't be adding it to the Add/Remove Programs, and in Program Files directory). Portable packages is also required to not need administrator privileges to be installed (this would require additional setup when installing choco though).
Now, a .install package usually is a wrapper around an officially provided installer, and usually requires administrator privileges as well as actually installs the program on the users computer.
(there are other differences as well, but this is the focus when thinking about this request)

Bottom line, there is only one thing that will make it a breaking change, and that is just the administrator change, but this is big enough breaking change that it should not happen.

[majkinetor]

Also, why do you have a problem with using portable version in which case you will remove intruder.

It actually got nothing to do with the program being available on the system path.

The fact that PATH changes is also a problem as some scripts certainly use full path to the putty executable.

All that being said, where is it stated that we need to maintain compatibility forever ?

[AdmiringWorm]

The fact that PATH changes is also a problem as some scripts certainly use full path to the putty executable.

While that is usually true, from my understanding this is not a problem when it comes to these two packages.

All that being said, where is it stated that we need to maintain compatibility forever ?

It is not stated anywhere, but when it comes to changing a portable dependency to a install dependency, then yes we should maintain compatibility (well maybe not forever, but a very long time).

Usually when there have been added breaking changes in the past, there have been made in a way that would allow existing users to keep their existing preference without making a change. In this case, we can not do that.

But let me ask you this.
Is this the way that you want to break compatibility, will you be dealing with the influx of emails from users telling us we have broken their usual builds? (This happens almost every time a breaking change have been made to a popular package, even when an upgrade path as been specified).

[cinderblock]

@majkinetor You did ask what I meant and I'm glad to have helped you sleep! 🎉

Back on subject, I've been installing PuTTY with chocolatey for years and every time (until recently because I started remembering) I would install the wrong PuTTY package only to wonder why my shortcuts/shell extensions aren't there and then spend 5-15 min researching only to finally remember, oh right, PuTTY is special because reasons.

---

I fully understand the implications of making even slightly breaking incompatible changes. Internet Explorer, for instance, decided to not make any breaking changes and built on legacy mistakes for decades which, ultimately, killed the product. I have no real problem with chocolatey going the same route but would prefer to just fix chocolatey. (I admit this is a bit of a stretch of a comparison, but the point stands).

IMHO, if it is broken, fix it. Depending on how many people will be affected, spend plenty of time making sure the transition is smooth.

I think it would be prudent to try to poll PuTTY users and see what the majority of us want.

If you really don't want to go through that trouble, fine. At least implement #1293 then.