200
Is Python's tooling incredibly difficult, or am I just stupid?
(sh.itjust.works)
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
Python developer here. Venv is good, venv is life. Every single project I create starts with
python3 -m venv venv
source venv/bin/activate
pip3 install {everything I need}
pip3 freeze > requirements.txt
Now write code!
Don't forget to update your requirements.txt using pip3 freeze again anytime you add a new library with pip.
If you installed a lot of packages before starting to develop with virtual environments, some libraries will be in your OS python install and won't be reflected in pip freeze and won't get into your venv. This is the root of all evil. First of all, don't do that. Second, you can force libraries to install into your venv despite them also being in your system by installing like so:
pip3 install --ignore-installed mypackage
If you don't change between Linux and windows most libraries will just work between systems, but if you have problems on another system, just recreate the whole venv structure
rm -rf venv (...make a new venv, activate it) pip3 install -r requirements.txt
Once you get the hang of this you can make Python behave without a lot of hassle.
This is a case where a strength can also be a weakness.
I hate this. Because now I have a list of your dependencies, but also the dependencies of the dependencies, and I now have regular dependencies and dev-dependencies mixed up. If I'm new to Python I would have NO idea which libraries would be the important ones because it's a jumbled mess.
I've come to love
uv
(coming frompoetry
, coming frompip
with arequirements/base.txt
andrequirements/dev.txt
- gotta keep regular dependencies and dev-dependencies separate).uv sync
uv run <application>
That's it. I don't even need to install a compatible Python version, as
uv
takes care of that for me. It'll automatically create a local.venv/
, and it's blazingly fast.I've never really spent much time with uv, I'll give it a try. It seems like it takes a few steps out of the process and some guesswork too.
Okay, now give me those steps but what to do if I clone an already existing repo please
The git repo should ignore the venv folder, so when you clone you then create a new one and activate it with those steps.
Then when you are installing requirements with pip, the repo you cloned will likely have a requirements.txt file in it, so you 'pip install -r requirements.txt'
You have been in lala land for too long. That list of things to do is insane. Venv is possibly one of the worst solutions around, but many Python devs are incapable of seeing how bad it is. Just for comparison, so you can understand, in Ruby literally everything you did is covered by one command
bundle
. On every system.OP sounds like a victim of Python 3, finding various Python 2 projects on the internet, a venv isn't going to help
This is the way
It's a stupid way
This is the way.