5 ms·

> whenever I install it via apt You have the option to create a virtualenv and install it with pip, or snap, or use a docker image. See [1]. This has a couple

> whenever I install it via apt You have the option to create a virtualenv and install it with pip, or snap, or use a docker image. See [1]. This has a couple of advantages: * you'll get the latest version from the maintainers - for instance right now only debian unstable has the latest 1.18.0 version - debian testing bundles 1.12.0-2 * you won't be adding system packages that might affect other parts of the system [1] https://certbot.eff.org/docs/install.html#alternate-installation-methods https://certbot.eff.org/docs/install.html#alternate-installa...

pbronez 5y ago
This might be a good scenario for pipx. It’s a Python package manager optimized for deploying applications instead of libraries. https://pypa.github.io/pipx/ https://pypa.github.io/pipx/
- memco 5y ago
  Use pipx-in-pipx to make it even more robust: https://pypi.org/project/pipx-in-pipx/ https://pypi.org/project/pipx-in-pipx/
  - gunapologist99 5y ago
    I hope this is a joke, right?
    - memco 5y ago
      Sadly, No. Thanks to the way Python works when installed via homebrew on Mac this is actually very necessary if you want to install system-wide python utilities that do not depend on the system python. Without it you can have these utilities broken by a system update or by a homebrew update that bumps the Python version.
throw0101a 5y ago
Which is another reason why I lean towards dehydrated when I can: a lot fewer "system packages" to deal with.
- gunapologist99 5y ago
  Link: https://dehydrated.io/ https://dehydrated.io/
traceroute66 5y ago
> You have the option to create a virtualenv and install it with pip, or snap, or use a docker image. You could jump through all those silly hoops (most of which will be completely alien to people who are not Python devs) in order to use the "official" dependency-heavy Python client. Or you could just use a single pre-compiled Go binary, LEGO [1]. I have been increasingly favouring Go recently because the functions delivered to the end-user are dependency free, you can just ship simple single binaries instead of having to say "oh you need Python X with this that and whatever other Python library under the kitchen sink installed on your system". And that's before we start talking about conflicts that can occur between Python libraries....which, let's face it will happen in an "average Joe" environment where Joe is just randomly using apt to install any Python dependencies. [1]https://github.com/go-acme/lego https://github.com/go-acme/lego
- cpach 5y ago
  Very good point. This is a great selling point for Go. It takes so much deployment pain away.
  - traceroute66 5y ago
    Indeed, for example this snippet from the Saltstack docs: >For historical reasons, Salt requires PyCrypto as a "lowest common denominator". However, PyCrypto is unmaintained and best practice is to manually upgrade to use a more maintained library such as PyCryptodome. See Issue #52674 and Issue #54115 for more info We wouldn't even be having that conversation with Go. There would be no weird "lowest common denominator" dependency. There would be no concerns about potential conflicts between other crypto libraries, and no choice to make about which "better" library you want to install. Plus of course the 10 other non-crypto dependencies that Salt needs. All you'd need is a binary, config file(s) and an init script and you'd be good to go.
    - nybble41 5y ago
      Sure, static linking and the like make the initial deployment much easier. On the other hand, it also means that any bugs in the dependencies are baked into each application, and fixing those bugs (which may be critical security issues) requires rebuilding all the downstream code. Provided, that is, you can rebuild the downstream code. Users of closed-source binaries are simply out of luck. Mixing multiple versions of the same (or closely related) libraries in the same program remains an issue even with self-contained applications. It might work out if the users of each version are isolated from each other, at the cost of program size and attack surface, but say you're using PyCrypto in one module and PyCryptodome in another, and you want to pass configuration or key information between them—the types won't match up. You'll also have two different API styles to deal with for the same tasks, which is bad for maintainability, which is ultimately bad for the user because it create more opportunities for bugs and makes it harder to implement new features and enhancements.
fake-name 5y ago
Which is unsupported and may explode randomly in the future. Like they did with `certbot-auto`. They only support snap. Which is fucking nuts.

pbronez 5y ago

This might be a good scenario for pipx. It’s a Python package manager optimized for deploying applications instead of libraries. https://pypa.github.io/pipx/ https://pypa.github.io/pipx/

memco 5y ago
Use pipx-in-pipx to make it even more robust: https://pypi.org/project/pipx-in-pipx/ https://pypi.org/project/pipx-in-pipx/
- gunapologist99 5y ago
  I hope this is a joke, right?
  - memco 5y ago
    Sadly, No. Thanks to the way Python works when installed via homebrew on Mac this is actually very necessary if you want to install system-wide python utilities that do not depend on the system python. Without it you can have these utilities broken by a system update or by a homebrew update that bumps the Python version.

throw0101a 5y ago

Which is another reason why I lean towards dehydrated when I can: a lot fewer "system packages" to deal with.

gunapologist99 5y ago
Link: https://dehydrated.io/ https://dehydrated.io/

traceroute66 5y ago

> You have the option to create a virtualenv and install it with pip, or snap, or use a docker image. You could jump through all those silly hoops (most of which will be completely alien to people who are not Python devs) in order to use the "official" dependency-heavy Python client. Or you could just use a single pre-compiled Go binary, LEGO [1]. I have been increasingly favouring Go recently because the functions delivered to the end-user are dependency free, you can just ship simple single binaries instead of having to say "oh you need Python X with this that and whatever other Python library under the kitchen sink installed on your system". And that's before we start talking about conflicts that can occur between Python libraries....which, let's face it will happen in an "average Joe" environment where Joe is just randomly using apt to install any Python dependencies. [1]https://github.com/go-acme/lego https://github.com/go-acme/lego

cpach 5y ago
Very good point. This is a great selling point for Go. It takes so much deployment pain away.
- traceroute66 5y ago
  Indeed, for example this snippet from the Saltstack docs: >For historical reasons, Salt requires PyCrypto as a "lowest common denominator". However, PyCrypto is unmaintained and best practice is to manually upgrade to use a more maintained library such as PyCryptodome. See Issue #52674 and Issue #54115 for more info We wouldn't even be having that conversation with Go. There would be no weird "lowest common denominator" dependency. There would be no concerns about potential conflicts between other crypto libraries, and no choice to make about which "better" library you want to install. Plus of course the 10 other non-crypto dependencies that Salt needs. All you'd need is a binary, config file(s) and an init script and you'd be good to go.
  - nybble41 5y ago
    Sure, static linking and the like make the initial deployment much easier. On the other hand, it also means that any bugs in the dependencies are baked into each application, and fixing those bugs (which may be critical security issues) requires rebuilding all the downstream code. Provided, that is, you can rebuild the downstream code. Users of closed-source binaries are simply out of luck. Mixing multiple versions of the same (or closely related) libraries in the same program remains an issue even with self-contained applications. It might work out if the users of each version are isolated from each other, at the cost of program size and attack surface, but say you're using PyCrypto in one module and PyCryptodome in another, and you want to pass configuration or key information between them—the types won't match up. You'll also have two different API styles to deal with for the same tasks, which is bad for maintainability, which is ultimately bad for the user because it create more opportunities for bugs and makes it harder to implement new features and enhancements.

fake-name 5y ago

Which is unsupported and may explode randomly in the future. Like they did with `certbot-auto`. They only support snap. Which is fucking nuts.