Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In my opinion, the worst problem is the lack of a standard way to handle dependencies. I recently had a hard time deploying a small Python project over a few heterogeneous Linux machines.

For example, this "simple, lightweight" program has dependencies, as one can see in its .travis.yaml file. That's why the readme has the command `pip install commonmark` (plus more dependencies for dev). But, wait, doesn't `pip` install as root in /usr/local/ by default? (BTW, the documentation of `pip install` is mute on the subject.) So I should use pipenv, but last time I tried it was broken and the ticket had low activity. So virtualenv + pip, but it's a mess since I like using many terminals. I've heard about poetry, but that's not standard at all...



You should use pip install --user, which pip will tell you about if you run pip install -h.

Virtualenv is usually excessive unless you have to handle lots of version problems


Dockerizing Python apps provides a nice isolation that makes managing dependencies across multiple apps much easier.


Why is virtualenv a mess with multiple terminals ? pip install for root unless you activate a virtualenv in which case it installs in it. If you make an alias of . env/bin/activate it is very simple, no ?


It is not hard, it is just folks desimplifying things to solve largely theoretical problems.

Just pip install to the location you choose. sudo or —user is fine 99% of the time. Venvs are only needed for big work projects.


Python deployment is a shitshow. Unfortunately mission critical stuff (looking at you letsencrypt) is also written in it which means that your systems are built on very shaky foundations.


What ? This seems like a bold affirmation. I find it very simple actually :

  apt install python3 virtualenv
  virtualenv env
  . env/bin/activate
  pip install -r requirements.txt
Done. And then with fabric you can automate deployments in a few lines of codes !


Right up until it nukes your perfectly working server.

The happy case works, it always does. The problem is in the edge cases and the exceptions. This probably goes for the bulk of all software.


Well in ten years I have never had a nuked server by pip or virtualenv. I am sure there are edge cases but that must be true for all the ways of deploying stuff. I guess the ones you know well appear simple to you !


I've had a production server be hosed by running 'letsencrypt-auto'. My bad I guess but still, that's one that I really did not see coming.


I kind of agree with both of you. I don't think Python deployment is that bad, as most modern managers get it right (I prefer Poetry nowadays). However something like letsencrypt-auto, which AFAIK installs its own dependencies, is not something I'd run. I've actually never used it precisely because it's too magical. Programs shouldn't install their own dependencies anywhere outside of a virtualenv.


Does certbot do the same ? I don’t use either so I can’t tell.

I strongly agree that any python program must install its dependencies in a virtualenv. One could even argue that this principle could be extended to any software !


Have you heard of our Lord and Savior pipx? Solves the python tool isolation issue nicely.


I haven't used it, I use virtualfish which does a great job as well.


Virtualfish is new to me, will check it out thanks.


And it turned out that pipx wasn't what I thought it was, so thank you as well! Though virtualfish is only useful if you use the fish shell.


People who know what they're doing can build a lot of things with python. It just so happens that I am not one of those people so I try to avoid it with a ten foot stick. I still use things built with python everyday.


We like `dehydrated` for ACME



Have you always used this or did you make a transition after LE burned you?


I heard about dehydrated from PythonAnywhere [1]. I haven't ever been burned by LE from a Python library, but I have had issues in the past with the kube-lego Helm chart not renewing as it should (easily fixed by deleting the pod though). [I know kube-lego is in maintenance mode now in favor of cert-manager.]

[1]: https://help.pythonanywhere.com/pages/LetsEncrypt




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: