Which reminds me that I need to revisit devcontainers for my work. When I first tried them, I ran into a few rough edges which might have since been resolved.
^1 Caveat, making a package of a Python project can be a rabbit hole can be a real pita. Virtual envs are usually good enough for most stuff until I start to need a compiler in every jail. Nowadays I'm looking almost only at Go (best) or Rust because their distribution is trivial in comparison.
Otherwise, I often find myself needing to deploy Python/Node/Ruby at $WORK and I'd really rather not try to get a bunch of dev/prod machines (possibly running different OSes!) trying to use whatever the flavor of the day for managing virtual environments, interpreter versions, packages, etc. is.
I've spent waaay to much time trying to docker build a python container with various combinations of apt-get/pacman/apk + pip/conda/venv
To move up a level of abstraction, though, the official Python image pretty much does The Right Thing by default (copy requirements.txt, pip install, execute some command, etc.). Of course that isn't going to work for every scenario but it's a good place to start.
It's not a solution it's a response.
It's "This thing makes no attempt to be portable or coordinate with the rest of the world, so the only way to package it is to include a copy of it's own entire world."
There is no excuse for a python script to be a hothouse flower.
It's one thing to choose to containerize something for your own operational reasons, but something else entirely for something to be so fragile that thst's the only way it even works is just you need a copy of the devs laptop.
It's garbage.