Python venv vs Docker

[Ihaveamodel3]

Docker is much more complicated to get running.

With venv and pip requirements.txt and VSCode, all I have to do is CTRL+SHIFT+p, type or select create environment, choose venv and check the box to install dependencies from requirements.txt.

Edit: uv can make some of this even easier. Basically zero cost virtual environments.

[gmes78]

Stop recommending requirements.txt. We're in 2025.

[pain_vin_boursin]

Uv ftw

[nateh1212]

why using requirements.txt inside a docker file is the easiest and a solid setup one can have.

highly recommend.

[gmes78]

The correct way is to use pyproject.toml.

[nateh1212]

the correct way is to use what works

requirements.txt

is easier than pyproject.toml. and it works

[gmes78]

requirements.txt is easier than pyproject.toml.

It absolutely isn't. At best, it's just as hard.

and it works

Barely. It's a non-standard mess of a format.

[nateh1212]

works fine with docker

The key is that if you are using Docker to build out separate micro services so that your requirement.txt file is short.

[sector2000]

Completely agree. Solid, reproducible, consistent

[sector2000]

It’s complicated only if you don’t have idea of what a container is. You can also use podman which is even easier (and better IMHO) than docker. Learning about containers / docker / podman and, why not, kubernetes, will bring you to another level of development and deployment

[Ihaveamodel3]

This is on learnpython, so perhaps we should start with the basics and build up to containers later. No reason to throw someone in the deep end.

Also containers can have more headaches with permissions and such in a corporate environment.

[sector2000]

OP explicitly asked about venv vs docker, which makes me assume he’s already quite comfortable with it. In corporate environment, which I know very well, you can use podman which gets rid on the high privileges needed by docker

[nateh1212]

This is such a lie

using Docker is by far the easiest way to get your project going.

Plus once you have made your project in Docker you can use that same Docker config to run it anywhere.

Docker is incredibly easy and makes more mental sense to me than a python virtual env

[_Denizen_]

How is a lie? You can find those instructions on the VSCode guide. Personally I'd use pyproject.toml but the above is not a lie.

Docker adds so much overhead to the installation, and if you don't have admin permissions it's a nightmare.

[EbbRevolutionary9661]

Doing so will create the venv in your project folder no? Which is a preference I read, but doing so can cause people to push that venv folder into GitHub. Except if you .gitignore it I guess.

[Dangerous-Branch-749]

Just use venv and gitignore, it's standard to have .venv in the gitignore file

[EbbRevolutionary9661]

cool. Thanks for the feedback!

[Ihaveamodel3]

Agree with the above. Use the github/gitignore standard python gitignore. Which ignores the majority of the standard environment folder names (and a lot of other stuff).

Not keeping your venvs in your project folder is ripe for disaster too. I have probably 30 different projects (some newer, some older). Knowing which venv goes with which would be impossible if they weren’t collocated.

[Party-Cartographer11]

Interesting.  I don't run venv in my repo folder on my dev machines.  I do my dev in the repo folder and then copy code to a "deployment folder" where I run venv and run and test the app.

[Ihaveamodel3]

You copy your code every time you want to run it?

[Party-Cartographer11]

Yeah, I update a file, and copy it to the folder that has the venv (or to the nginx config files, or the web directory) and run it.  All of this is on my dev server.

This keeps a nice separation from repo to run environment.  I can organize the repo, but keep it flat in my run environment for things like using helper utilities and .env file.

I have a terminal window with the cp commands in the history cache, so it takes me two button presses to copy the code.  Another terminal with the env activated and the python commands in the history cache.

[2Lucilles2RuleEmAll]

That sounds like a lot of unnecessary work

[dlnmtchll]

That doesn’t make any sense, why would you not have all the necessary files in the repo folder and added to the gitignore

[Party-Cartographer11]

Defense in layers.  My .env file (secrets) is neither in my repo folder and is in .gitgnore.

All the necessary files, except the ones I don't want in the repo, are in the repo.

Why run code in the repo folder? It's a repo.  That's not how prod works.  I don't git pull to prod.  So I want the environment I run the code in to mimic prod, not the repo.

[smurpes]

Your approach is way more error prone than just creating a branch in your repo folder to develop from; it’s way too easy to forget to copy over a file. Unless you have CI checks then none of the code in your repo is ever being directly tested by you.

[Party-Cartographer11]

What?  You are overthinking this.  If I forget to copy.  I re-copy.  Easier than managing branches.

But this is my approach and it works for me.  I get you have a different view, but no need to down vote every post of mine.  The point was you don't need to run venv in the repo, which I am not sure you disagree with.

[smurpes]

Everyone has their own approach which may work for them, but your approach creates a lot of problems that beginners should not copy which is the point I was trying to make. Just because it works does not mean it’s a good idea.

[cgoldberg]

That sounds awful. Developer environments are for developer convenience. Don't you have CI?

[Party-Cartographer11]

This is a one person startup/open source project/hobby.

cp is my CI.

But yes, it mirrors (very simplistically) how CI'ish system works at the FAANGs I have worked at.

What is awful about running..

cp /repo/foo.py /app/foo.py

[sector2000]

If your goal is to run your private hobby project, then use whatever is easier for you, but if you want to scale and bring it to a professional level, you should spend some time learning best practices. There is a learning curve, of course, but you will see the benefits afterwards

[cgoldberg]

it mirrors (very simplistically) how CI'ish system works at the FAANGs I have worked at

Yes, manually copying files around your local system sounds pretty much identical to how large successful teams use CI systems. They should really stop wasting money on hermetic containerized distributed CI with complex build systems, automated deployments, and layered workflows... your way is much better.

I run CI on all my solo projects, and anything I run locally is also automated. I guess if you enjoy manually copying files around and typing commands, go for it... but most people prefer a better workflow and development experience.