[chpmrc]

- Poetry is a 3rd party package manager, I'm sure it's great but it's not widely used (yet)

- Pip freeze just pins all dependencies at once to requirements.txt

- I don't know what "vendoring in dependency code" means

- I've never used pipreqs in my life (and 80% of my work has been in Python)

- Virtualenvs are just a convenient way to keep project runtimes separated

And for 90% of Python projects in existence the following is sufficient (assuming Python3 is installed):

- python -m venv .venv

- source .venv/bin/activate

- pip install -r requirements.txt

That's it. And all of that requires a single dependency: Python. Could it be better? Sure. But to call that a "mess" is an exaggeration.

[linsomniac]

"Vendoring" means including the library in your package. So instead of listing it in requirements.txt, you copy the code of the library.

[giantrobot]

You can get that by bundling up your venv. When you install a package is a venv it installs it into that venv rather than the system. As far as the venv is concerned it is the system Python. Unfortunately passing around a venv can be problematic, say between Mac and Linux or between different architectures when binaries are involved.

[KptMarchewa]

>- python -m venv .venv

>- source .venv/bin/activate

If those two steps were automatic like in node.js we'd literally have 99% less problems.

[jeremydw]

Sounds like someone has never been asked to clone and run software targeting Python 3.x when their system-installed Python is 3.y and the two are incompatible.

[Spivak]

Then you use pyenv and pyenv virtualenv.

    pyenv install 3.9.47
    pyenv virtualenv 3.9.47 my app
    git clone …/myapp
    cd …/myapp
    pyenv local myapp
    pip install -r requirements.txt

Is it annoying, maybe, but I normally don’t trust system deps for anything.

[chpmrc]

Sounds like someone is making assumptions on the way I work :) As a matter of fact I have and the solution is pyenv. Node has a similar utility called n.