It’s too fucking hard to setup python with all its pyenv, anaconda, poetry, pip requirements.txt and what-not, that’s the best use case for Docker here. Get it to work once and forget about it.
In my ideal world, everybody would just use what comes with vanilla Python:
python3 -m venv venv
source venv/bin/activate
(Or `call` on Win)
pip install -Ur requirements.txt0: https://github.com/rmpr/atbswp
1: https://mobile.twitter.com/gvanrossum/status/130608247244308...
Dealing with BC breaks for versions you aren't intending to run in production seems like unnecessary overhead.
apt install python3-venv
#!/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" "$@" ./the-programDocker does it for you.
pipenv init
Pipenv install
My team insists on using Docker and against my better personal judgement I let it, but I set up the code to run locally without it. If I call the shots I'll not use docker absolutely.
1. Open a port on the container for debugging
2. Tell the debugger in the container what's the port it should use (if you're not using the default one)
3. Tell the IDE what port it can use to connect to the debugger (if you're not using the default).
4. Debug it!
For things like Typescript you might need some extra trickery because it's all transpiled, so you'll need to make sure your sourcemaps are set up correctly, but that's not overly difficult.
It did take me several hours to work everything out and write a README so that every time we get a new hire / someone sets up a new PC they can just follow the instructions. I'd say it was time well spent.
Inside containers and without Docker alike.
The team would no longer have to make these deployment decisions and argue about which tool is a better fit. They'd make the decision once, hopefully follow best Docker practices (unprivileged user, multi-stage builds, etc.), and have documentation available for how to integrate the setup with IDEs, work with volumes, etc.
Once this initial adoption hurdle is overcome, IME the productivity gains are greater than the issues of dealing with Docker. It becomes trivial to setup CI/CD, onboard new developers and integrate the app into other workflows.
Docker and containers in general have become mature enough to prove their use case and benefits, so the cargo cult argument doesn't hold weight for me.
But true, you weren't supposed to need it. But managing projects with interlocked dependencies get old fast.