You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pipenv is able to locate the environment location for a given project directory using the folder path and hash, but not the other way around (I think...?)
In other words, given a pipenv Environment folder (eg. ~.local/share/virtualenvs/project1-12345678),
there is no way of knowing what is the corresponding project directory.
It is possible, however, from a given Project Directory, to resolve the corresponding environment location - if there is one.
Let's say the environment above was create from the location: ~/dev/project1.
From this directory, a user could run: pipenv --venv, and the output would be:
~.local/share/virtualenvs/project1-12345678
(if pipenv --venv is run from a directory with no corresponding venv, the output is:
No virtualenv has been created for this project yet!
For Pipes to work properly and be able to to Activate AND cd into the project directory (similar to workon), we currently need the user to manually create this "link", and this is done as following:
From ~/dev/project1, user creates a new pipenv environment by running pipenv install
A new enviroment is created by pipenv: ~.local/share/virtualenvs/project1-12345678
User runs: Pipes --link .
Behind the scenes, Pipes will run pipenv --venv from the current location (.), and the result will be: ~.local/share/virtualenvs/project1-12345678
The command output is written into a file ~.local/share/virtualenvs/project1-12345678/.project
The .project file will help Pipes know what directory to cd into.
User runs pipes project1
Pipes resolves the environment by name, and looks for a .project file *
If present, it cds into that directory, and activates the env shell.
* If a .project file is not present, use needs to perform step 3.
For this to happen, we need to have pipenv store the project location into the environment it creates.
Virtualenvwrapper does that by storing a .project. The project path is set manually by the useer (setprojectdir .)
With pipenv that should be even easier than for virtualenvwraper, since the enviroment is always create FROM within the project directory.
All we would need to do is save that location inside the enviroment in a .project file.
pypa/pipenv#1861 is reasonable enough, and does not affect anybody negatively anyway. I’m inclined to merge it because why not. (I actually planned to do so yesterday, but our tests got completely broken and I had to fix that first.)
Pipenv is able to locate the environment location for a given project directory using the folder path and hash, but not the other way around (I think...?)
In other words, given a pipenv Environment folder (eg.
~.local/share/virtualenvs/project1-12345678
),there is no way of knowing what is the corresponding project directory.
It is possible, however, from a given Project Directory, to resolve the corresponding environment location - if there is one.
Let's say the environment above was create from the location:
~/dev/project1
.From this directory, a user could run:
pipenv --venv
, and the output would be:(if pipenv --venv is run from a directory with no corresponding venv, the output is:
For Pipes to work properly and be able to to Activate AND cd into the project directory (similar to
workon
), we currently need the user to manually create this "link", and this is done as following:~/dev/project1
, user creates a new pipenv environment by runningpipenv install
~.local/share/virtualenvs/project1-12345678
Pipes --link .
pipenv --venv
from the current location (.
), and the result will be:~.local/share/virtualenvs/project1-12345678
~.local/share/virtualenvs/project1-12345678/.project
.project
file will help Pipes know what directory to cd into.pipes project1
.project
file ** If a
.project
file is not present, use needs to perform step 3.Solution
--link
step #3 above should be removed entirely.For this to happen, we need to have pipenv store the project location into the environment it creates.
Virtualenvwrapper does that by storing a
.project
. The project path is set manually by the useer (setprojectdir .
)With pipenv that should be even easier than for virtualenvwraper, since the enviroment is always create FROM within the project directory.
All we would need to do is save that location inside the enviroment in a
.project
file.Related PR:
pypa/pipenv#1861
@meshy @uranusjr
The text was updated successfully, but these errors were encountered: