pipenv install --target /path/to/my/virtualenv/folder

Hi,

Could it be possible to create the virtualenv in the folder of our choice instead of ~/.local/share/virtualenvs/ ?

for example

pipenv install --target ~/fox_venv/projectA

which will create the venv in ~/fox_venv/projectA and not in ~/.local/share/virtualenvs/projectA-XdFl1243x

Regards

[nateprewitt]

Hey @foxmask, you can set the PIPENV_VENV_IN_PROJECT environment variable to have pipenv place the .venv directory inside your project rather than with the others in .local.

This is likely the closest we'll get to your current request for now. Hopefully that helps accomplish what you're looking for. Thanks for taking the time to check in on this!

I saw it but the ~/fox_venv/projectA/.venv/ folder is not the folder I've chosen, but if it's how that has to work, I bow.

[davipo]

See https://docs.pipenv.org/advanced.html#custom-virtual-environment-location
I've got this line in ~/.bash_profile (on macOS):
export WORKON_HOME=$HOME/.virtualenvs
Maybe you could set WORKON_HOME when switching projects.

[hellupline]

the pip install --target have other uses than using a venv

I use pip install --target dist/ libs/lib1 libs/lib2 .... app/src to create a dist.tar.gz with all dependencies and then I use docker add plus PYTHONPATH to bundle the application with custom libraries

I would be really good to use pipenv install --target dist/ with its lockfile

[rajasimon]

I want this feature too. I've the private repo to be included in vendor/ folder. It will be nice pipenv have this feature like

botter-library = {git = "ssh://git@server/user/repo", ref = "v0.0.1", target = 'vendor'}

[mdeguzis]

It is a shame that there can't be a hook that just sets WORKON_HOME for that invocation or set's it for the project context.

[techalchemy]

@mdeguzis the workaround we've suggested in the past is to use a tool like direnv to handle the context switching for you

[jakul]

I was able to workaround with:

pipenv run pip install --target dist/

[kevinkjt2000]

It seems that supporting this feature would not be too much work, since pipenv can already do this:

pipenv run pip install -r <(pipenv lock -r) --target dist/

[uranusjr]

@kevinkjt2000 Yeah, our code base is so easy you never contributed anything.

[kevinkjt2000]

@uranusjr I acknowledge that you have a collaborator badge, but that is a rather sarcastic comment to make... I encourage you to encourage potential new-comers instead of steering the github comment section into frivolous, insulting conversations. If you would like more contributors; instead, try confirming or denying comments as they are made. Sarcasm is rather off-putting. I used the word seems, because of how unsure I was.

My comment pointed out that pipenv is capable of knowing what requirements are to be installed with lock -r and that pip is capable of installing that list of requirements. In my mind, pip seems to be the foundation behind how pipenv installs packages; however, as I am new to pipenv it only seems that way. I thought that in making the comment on an issue where it was stated that This is likely the closest we'll get to your current request for now. on late September last year, that perhaps someone more knowledgeable would re-visit and consider if it was easier after a few months of contributions and given that bash shell one-liner that I posted.

[kevinkjt2000]

That being said, I'm willing to take a crack at this. I shall poke around for a bit, and see if there is a place to inject the --target option to pip, or perhaps I shall find out that pip is not the backbone of this project that I thought it was. Who knows?

[techalchemy]

@kevinkjt2000 @uranusjr is as much of a core maintainer as it is possible to be at the moment, no matter what his tag says, but you're right that you are just trying to help and I'm quite sure he misunderstood your intentions, so firstly apologies for that

Technically you're right, pipenv can really support anything because you can pipenv run <x> -- but I understand the need for this (we have somewhat complicated infrastructure and tooling built around vendoring libraries ourselves so I do feel your pain. However, I think we want to first get our core library 'well oiled', then focus on these things.