(putty) should depend on putty.install not putty.portable

cinderblock commented 5 years ago

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:

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

majkinetor commented 5 years ago

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 commented 5 years ago

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

stale[bot] commented 5 years ago

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

cinderblock commented 5 years ago

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 commented 5 years ago

What does that even mean ?

cinderblock commented 5 years ago

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 commented 5 years ago

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

AdmiringWorm commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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.

chocolatey-community / chocolatey-packages