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.
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.
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.
- 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.