Let user choose location of .venv

It’s irritating that you cannot specify custom virtual environment directory location. It makes pipenv unsuitable for production deployments. PIPENV_VENV_IN_PROJECT is suitable only for development environments.

Consider this scenario using docker-compose.yaml to set up a Docker container:

...

  install:
    image: python:3.8
    environment:
      PIPENV_VENV_IN_PROJECT: 1
    volumes:
      - /srv/deploy/app:/app:ro # Note that this is bind mounted read-only
      - /var/cache/libgen-tools-venv:/app/.venv
    # Pipenv writes by default so we pass --keep-outdated
    # because Pipfile.lock is on read-only filesystem.
    command: pipenv sync --keep-outdated

  periodic-batch-job-1:
    image: python:3.8
    environment:
      PIPENV_VENV_IN_PROJECT: 1
    volumes:
      - /srv/deploy/app:/app:ro # Note that this is bind mounted read-only
      - /var/cache/libgen-tools-venv:/app/.venv:ro
    command: pipenv run python3 /app/dostuff.py

  ...

Here the project is deployed out of Git/CI/CD into /srv/deploy/app and is mounted read-only to containers at /app, because more containers share the same code and they have no business overwriting it. But this means that /app/.venv cannot be created in containers.

This is very specific example I’m now just dealing with, but having virtual environment in /var/cache or any other volatile directory seems to be perfectly legal usage.

I’ve experimented with exporting VIRTUAL_ENV prior to running pipenv install but it is ignored.

This issue was previously closed here https://github.com/pypa/pipenv/issues/746.

[OrangeDog]

@ZelphirKaltstahl but pipenv should create and activate the virtualenv as necessary, otherwise you way as well just use pip freeze.

[techalchemy]

Hey there, sorry you’re running into this frustration – I’ve struggled with this myself and I definitely hear you. You have a couple of options already which address this use case broadly speaking – not all of these will apply to your specific use case but I will include them in case they help anyone else:

1. Setting VIRTUAL_ENV should work ok, as should sourceing a virtual env before invoking any calls (though you’d have to do so ahead of each call);
2. You can include a .venv file which contains text with a path to a virtual env, e.g. /path/to/some/venv_base, which pipenv will then treat as the actual environment;
3. You can forego the virtualenv entirely and install using --system – this would install directly into the container’s environment obviously, so YMMV;
4. You can set WORKON_HOME to /var/cache/app_venvs and make sure to create the directory and give whomever will be writing the appropriate access; pipenv will then automatically create the virtualenv there based on a deterministic hash of the application path

As for the comment in there about pipenv writing everything it sees, yeah, that issue is also super annoying. I expect to tweak that API a bit sometime soon to try and make that a bit less painful.

Let me know if any of that can meet your use case – thanks!