Strategic choice for bash installer

[dispyfree]

Hi all,

this question is of generic nature and not related to any specific problem I have with pants. In fact, I am just getting started with pants and am currently devouring the documentation :)

As per official documentation, pants is to be installed via a bash script that we pull off the pants domain. I've been noticing that kind of installation with a number of other projects as well, in particular I can think of terraform and Microsoft products. This has been gaining traction, as I used to be able to install everything off a package manager just a decade ago.
Whenever I see that, I am wondering why no package manager was used instead. There must be a solid reason and I'd like to know why :)

Package managers are there for a reason and foregoing that by running a simple shell script is inevitably going to reintroduce all the problems that package managers used to solve. So I'm really curious to hear what the reasons were to go down this route instead. I haven't personally managed installation procedures for any large scale project so I really have no insights there just yet.

I am looking forward to your answers!

With best regards!

[kaos]

I think the short answer is: portability.

Every system has their own package manager(s), and to support them all would be a big undertaking. We do support (since recently) to install pants using Homebrew as a convenience/alternative to using the bash script installer for MacOS users, as noted on the page you linked to with:

brew install pantsbuild/tap/pants

[jsirois]

+1 - its a ton of work and expertise to support rpm / deb / whatever MS uses (? .msi) / homebrew and then the ones we missed because that doesn't cover it (Arch PKGBUILD, Chocolatey, ...).

[jsirois]

Another thing to point out is there is no installation here! The script is a distraction. You could just download the single file native binary - a thing that needs ~no installation by definition: https://github.com/pantsbuild/scie-pants/releases

Traditional package managers vs single file static binaries like this are definitely a weird fit. Perhaps that is a better place to put the scrutiny. The scie-pants binary is truly static (on Linux). And so you can't fix it by - say - upgrading OpenSSL on the host, its got its own included. That of course speaks to the 2nd conflict with traditional package managers - you waste some disk space here by not sharing an OpenSSL dynamic lib.

So the real driver here is the rise of languages that produce static binaries like Go, and in this case, Rust.

[sureshjoshi]

What's a bit funny about pseudo-"install" scripts like this one is that it's 225 lines of code to roughly say this with variables safely and automatically put in (from the scie-pants Readme):

curl -fLO https://github.com/pantsbuild/scie-pants/releases/download/v0.5.4/scie-pants-linux-x86_64
curl -fL https://github.com/pantsbuild/scie-pants/releases/download/v0.5.4/scie-pants-linux-x86_64.sha256 | sha256sum -c -
chmod +x scie-pants-linux-x86_64 && mv scie-pants-linux-x86_64 ~/bin/scie-pants

[jsirois]

Agreed! I think it would be much better if folks could just handle an iota less of convenience. Triply so when those folks themselves are developers by definition. Anyone installing a software build tool should be able to handle that surely.

[thejcannon]

I don't completely agree. Date scientists are not software engineers and don't have the same background as we do.

They write software, sure, but it's very much a means to an end and understanding the ecosystem and it's nuances is a distraction from the real work.

[dispyfree]

Thank you for the insights! That answers my question - feel free to close this if you prefer to keep the board clean.

@jsirois

So the real driver here is the rise of languages that produce static binaries like Go, and in this case, Rust.

That is an interesting aspect which I did not have on my mind at all.

While we're at it, a related question: Why would people use

• the central package management system but
• spin up their own repository and force you to add theirs?

Microsoft is really big on doing that. Also for simplicity? My fear here is that public repositories have (quality) standards, whereas private ones just don't.

@jsirois I used to pull source files and install shit by running make. Since the advent of UI, Android & Low-Code, I don't think people can be bothered at all. If things do not run by a click of a button, they turn away in disgust. :-D

[jsirois]

Microsoft is really big on doing that. Also for simplicity?

I think so, yes. They are less lazy than me here. They don't whine about the complexity of supporting packaging formats, but they don't get their packages accepted into the canonical repo either. No doubt some bit of branding plays in too though as well as some bit of lock in - they know you need to use their custom package repo and may complain but probably won't walk away.

[jsirois]

Since the advent of UI, Android & Low-Code, I don't think people can be bothered at all.

Yeah. I still swear at the merge button's influence and appreciate and agree with Linus' somewhat famous GH rant on the Linux GH mirror PR.