I also dislike all the commands you just mentioned. In my ideal world, everybody would just

    ./the-program

And then ./the-program breaks and someone has to read its source code. Then, the fewer dependencies the-program has, the easier it will be to fix.

Sounds wonderful compared to dealing with Python tooling.

It's all fun until one of your requirements needs a billion build dependencies to be available on a machine. How do you solve that with pyenv?

Docker does it for you.

I agree. I suspect Docker does make sense in such projects. In my pretty vanilla web development, I just usually don't experience this.

I agree. Python's virtual environments are awesome and easy to use. On a new server just start with

    apt install python3-venv

Really easy to source the environments as needed during automation, etc.

and pipx for managing python "apps" like youtube-dl, ipython, meson, ...

https://pipxproject.github.io/pipx/

I prefer my system for running youtube-dl in an isolated environment without having to install all of its dependencies on the host. Ansible writes a bash script at ~/bin/youtube-dl containing:

  #!/usr/bin/env bash
  set -e

  IMAGE_NAME="grepular/youtube-dl"

  # Build the image if it does not exist
  if [[ $(podman images --filter "reference=$IMAGE_NAME" -q) == "" ]]; then
      podman build -t "$IMAGE_NAME" -<<EOF >&2
  FROM python:3-slim
  RUN python3 -m pip --no-cache-dir install youtube_dl
  ENTRYPOINT ["youtube-dl"]
  EOF
  fi

  podman run --net host -i --rm -v "$PWD:/app" -w /app "$IMAGE_NAME" "$@"

Pipx is pretty much that - installs a package into its own venv and links script entry points to .local/bin

QQ, aren't the created files owned by root?

Nope. I'm using podman rather than docker so they're owned by the user that runs the script. The root user isn't involved. If I were using docker, I'd add `-u "$(id -u):$(id -g)"` to the docker args to deal with that issue.

I’ve been doing a manual version of this for years, creating a shell shim wrapping a venv for cli tools. This is much neater, thanks!

I dunno, these magic incantations make a lot less sense to me than:

  pipenv init
  Pipenv install

Maybe it’s because I’m used to npm and composer?

Venv is great for keeping dependencies separate but if your local machine doesn’t have the same version of Python as your server then you’ll need pyenv.

Not necessarily, you can use a CI pipeline to verify that your project can be build with many Python versions. This is the workflow I use here[0]. It makes catching and fixing breaking changes easier. Plus, I'm confident the core team is not likely to introduce a painful breaking change (think Python 2 -> 3) soon[1]

0: https://github.com/rmpr/atbswp

1: https://mobile.twitter.com/gvanrossum/status/130608247244308...

That's great for libraries but isn't it a pretty huge cost for an app you only really are going to be running on one version at a time?

Dealing with BC breaks for versions you aren't intending to run in production seems like unnecessary overhead.

You must be the only person who ever runs that on your own code because you skipped the pyenv step