Sorry Python but it is what it is.
this post was submitted on 13 Oct 2023
324 points (81.4% liked)
Programmer Humor
32549 readers
478 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Pip stores everything inside of some random txt file that doesn't differentiate between packages and dependencies.
Pip stores nothing in a text file
If you want to export your local environment, isn't usually a requirements.txt used?
Isn't it called a requirements.txt because it's used to export your project requirements (dependencies), not all packages installed in your local pip environment?
Yes, but this file is created by you and not pip. It's not like package.json from npm. You don't even need to create this file.
Well if the file would be created by hand, that's very cumbersome.
But what is sometimes done to create it automatically is using
pip freeze > requirements. txt
inside your virtual environment.
You said I don't need to create this file? How else will I distribute my environment so that it can be easily used? There are a lot of other standard, like setup.py etc, so it's only one possibility. But the fact that there are multiple competing standard shows that how pip handles this is kinds bad.
If you try to keep your depencies low, it's not very cumbersome. I usually do that.
A setup.py/pyproject.toml can replace requirements. txt, but it is for creating packages and does way more than just installing dependencies, so they are not really competing.
For scripts which have just 1 or 2 packges as depencies it's also usuall to just tell people to run pip install .
I work with python professionally and would never do that. I add my actual imports to the requirements and if I forget I do it later as the package fails CI/CD tests.
Honestly its a simple and straightforward solution. What's wrong with it?
If newer versions are released and dependencies change you would still install the old dependencies. And if the dependencies are not stored you can't reproduce the exact same environment.