Hacker News Reader

Comment by nejdetckenobi | Hacker News Reader

normally I use virtualenvwrapper and that makes a virtualenv directory for all virtualenvs you create with it. before that, I always create my projects' venvs inside my project hierarchy.

I had a dilemma about it. But after all, you can not move your venv directory unless you use `--relocatable` option. So, anyone have a strong argument about creating venvs inside your project directory?

View on HN

I've always found the whole virtualenv stuff so superfluous. Do we really need all the machinery with shell scripts and static paths?

We just use a directory where we keep our dependencies. It's a matter of:

    mkdir libs
    pip install -t libs <package>
    # then to run
    PYTHONPATH=libs python app.py

From what I can tell, this accomplishes everything a venv does (except bringing the Python interpreter itself along) without requiring any extra tools or conventions to learn.

As you pasted-it, it does not accomplish venv:

  - you still need to change PYTHON_PATH to recognize libs from `libs`
  - packages have bin scripts sometimes that most likely, will be needed by the project

A more proper command: - pip install -t ./libs --install-option="--install-scripts=./bin"

But still, does not solve the PYTHON PATH issue, it won't be solvable because all python cli tools and all scripts in ./bin must be aware of PYTHON_PATH including ./libs

This is what venv does and pip alone cannot easily solve, replicating an entire python environment that is aware of project local pip packages

My commands do set PYTHON PATH when running the app.

As for the cli tools, fair enough, but the packages I use with such tools/scripts are full applications, not dependencies to be included in another project. Which kinds of packages do you see as both dependencies and containing CLI tools?

No, you still don't have:

- ./bin. No commands for you.

- a way to specify your libs to a program not providing a way to set env var.

- isolation from the system stdlib. This will cause subtile bugs.

- a clean pip freeze. No deps listing.

- and hence a lock file.

I just keep venvs in the project folder and add them to .gitignore. --relocatable never worked well for me, I just keep my requirements.txt up to date so it's trivial to blow away a venv and recreate it if necessary (python3 -m venv env && source env/bin/activate && pip install -r requirements.txt).

I find tools like virtualenvwrapper and this one from Kenneth tend to solve issues I don't really have. A little bit of repetitive typing here and there is ok to burn knowledge into my mind; and less leaky abstractions I have to deal with, the better.

It solves more than that:

- beginers don't have to understand the whole virtualenv shenanigans. I use pew myself to replace virtualenvwrapper but I will switch to pipenv just to ease the pain of team member joining in.

- it enforces good dependency management practice with the toml file and lock file. This is an issue in almost all project I worked on, including ones from Python experts. We all use only requirements.txt file out of convenience, and never lock.

- it's one tool to do all the packaging stuff. No need for pip and virtualenv and a wrapper. You got one command.

Reply on news.ycombinator.com