Is this stance gate keeping users? Isn't a pkg manager installation also a one liner? This seems more like gate keeping lazy distributors.
Users need to figure out which of the 10+ package managers they should be using, then run several commands. If something fails, the error messages are often cryptic and not easily configurable by the distributor.
And that’s before getting into the many rough edges of package managers. Most of them flat-out refuse to handle configuration and leave that part to the end user. Now you also need to document how to edit YAML and restart a systemd service. With an install script this is also solved.
For power users, this always looks trivial. In practice it raises the barrier to entry and can meaningfully affect adoption if your product is often used by less technical people.
In what world does a user have to choose between 10 package managers? Each distro has exactly one. There are also only about three, maybe four main package managers out there.
A shell script being piped into bash has so many more ways to break than a package. And if yhe theory is that package managers are fickle (they aren't), then how does adding more complexity help?
It is much simpler, much safer, and easier to maintain a package than an install.sh, eapecially for a big project.
Configuration can be handled by a script, yes. Here's a crazy idea: Your package can include scripts for configuring the software. It's almost as if most packages do. The scripts/utilities could even restart a systemd service for you.
Unless you're talking about configuring your build, in which case we're dealing with an experienced developer who will have no trouble just cloning the repo and building from source.
My biggest issue is: if we're dealing with someone who can't use a package manager, we're dealing with someone who doesn't have the capacity to judge how safe a script downloaded off the internet is. This does not drive linux adoption, it drives botnet adoption.
I'll stop there. I'm not interested in continuing this discussion when it's being conducted in bad faith.
Rather than argue with those of us who are pointing out messy realities, this commenter might be better served filing a bug against any number of the projects that offer installation this way, asking them to remove it, and see if it lands any better.
Technical purity/superiority isn’t the only factor, or even the most important one, driving projects to offer quick installers like this.
I would also appreciate it if you actually talk about something concrete rather than simply claiming to be right. You shouldn't pipe stuff from the internet into your shell.
Are you claiming that's about some highfallutin "technical purity"? Is it technical purity to check inside the bag when you buy a pig in a poke? No, that's common sense. It's common sense to have some degree of knowledge about what programs you execute on your computer. As root, at that.
Nobody would argue that it's categorically safe/good/smart to blindly pipe a script into your shell; and for the record, I agree. I would also readily agree that habituating users to doing this probably creates new, more general risks especially among how less-technical users interact with their CLI.
However, the realities of the "real world" make it popular for a reason, in light of those negatives; tons of scaled projects continue to offer a 1-liner. So we have to ask, why? They'd probably say that's because it (a) improves project adoption, and (b) reduces "install broken" tickets.
You have to address the non-technical merits and goals to get behavior to change here, and sadly, I don't think anyone has done that.
But who cares about me? I'm not currently maintaining one of these (though I did once). My suggestion to bring your argument to an active project was genuine: try it! I'd be delighted to see you bring about the change you want.
[PS: The commenter I replied to originally used the term "bad faith", which they've since edited]
I am arguing in good faith about the merits of the approaches. I am engaging with the points of argument being brought up from the opposing side of the argument (see above). I am not veering off on side-tracks, unlike you, for example.
There' a simple good faith argument (that I have been making) which you can try responding to: Running arbitrary code from the internet without checking is bad. There is some effort needed to package software, but that is not that much effort in the grand scheme.
IMO a lot of the blame falls onto the package manager ecosystem refusing to take into account very valid needs and claiming they aren't real / desirable.