Hacker News Reader

Comment by pdkl95 | Hacker News Reader

Why does

    ./letsencrypt-auto --help

run my package manager? Asking for the command's help text should never cause some side-effect to happen.

https://www.gnu.org/prep/standards/html_node/Command_002dLin...

https://www.gnu.org/prep/standards/html_node/_002d_002dhelp....

edit:

Ok, this is a little disappointing:

https://github.com/letsencrypt/letsencrypt/issues/1286

    We need to install our dependencies before we can install ourselves
    and be able to produce output for --help.

That's fine. Then the --help pre-install should simply produce a message explaining this.

Fortunately, it seems I'm not the only person who thinks running an install when someone asked for help is not good behavior:

https://github.com/letsencrypt/letsencrypt/issues/1903

View on HN

When I ran it, the first thing it did was ask for a sudo password. Um, no. I ran it on a test machine and it installed a bunch of dependancies without even so much as asking. Again, no. For something that is supposed to be securing systems, it sure seems insecure.

Totally agree that this is not optimal, but bear in mind that the goal is to get letsencrypt shipped through your package manager, where it can just specify dependencies and the package manager will resolve them. With that, this will essentially become a non-issue.

I've been thinking a bit about python and packaging, and I think there are few reasons to wrap the bootstrap process of packages like this in a shell script. As python is already a hard dependency, it should be somewhat easier to write a cross-platform bootstrap in python, than in posix shell (hello, windows?). It is a little unfortunate that expressing "needs python, headers and a c compiler" is as hard as it is. But if dependencies are beyond the (reasonable) reach of pip/setuptools, it seems it might make sense to simply defer to some other package that already deals with this stuff, such as ansible.

Nothing against automating systems with shell (or Makefiles) -- but it seems to result in much duplication of effort (eg: duplicating stuff from the "os" package in python's std lib) -- with an added burden when trying to support a variety of Linux and * bsd distros.

Writing a posix shell installer that works "idiomatically" on Debian is easy. Writing one that works across old-stable, stable and testing is a little more complex. Adding support for Ubuntu LTS along with the slew of Ubuntu-releases newer than previous LTS, can already get messy. Add inn SuSe, RedHat, Arch, Slackware and GNU Guix... and that's not even thinking of Open Solaris or the * BSDs.

It's not that it can't be done, but I think the only sane choice is to get upstream to do the hard work (eg: port/package python w/"os", port/package ansible -- or use something else, like package-config or ... autotools...).

I think the best way is probably to distribute a python script that sets up a virtualenv, and runs pip from within that to pull down/set up a package. I'm not yet quite sure if this is viable for python2x though... bringing venv into the std-lib is one great (and I think often overlooked) feature of python3.

I suspect you may be missing my point. I don't care about the use of the package manager. The problem is that it shouldn't be run when I asked for documentation.

edit:

Understood, and yah, --dry-run support would be great, but I'll settle for working documentation.

Oh no, I agree with your point, too. But I think they are related -- even if there's no reason not to put the full help-text in a here-document (or an actual file, as long as the expected usage is to git clone first - the python code and the shell script could use the same help-text) -- I see few people/projects providing real help texts in their shell scripts.

Generally, people are very sloppy with handling arguments to shell scripts (probably because it requires a bit of boilerplate). But a nice '-h|--help' and maybe '-n|--dry-run' would be good to have.

I agree, but it's a beta. Constraints happen.

An application should never try to invoke your package manager, unless its specifically for that purpose. That's just totally backwards.

Yeah, this sucks.

You can install the Let's Encrypt client in a way that you actually have control over by using the GNU Guix package on any GNU / Linux distro.

The installation has no side effects to your system (since it's Guix / Nix) and the myriad of dependencies is packaged and versioned.

Reply on news.ycombinator.com