Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Env <> Project Linking #5

Open
gtalarico opened this issue May 4, 2018 · 1 comment
Open

Improve Env <> Project Linking #5

gtalarico opened this issue May 4, 2018 · 1 comment
Labels
enhancement New feature or request
Milestone

Comments

@gtalarico
Copy link
Owner

gtalarico commented May 4, 2018

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:

  1. From ~/dev/project1, user creates a new pipenv environment by running pipenv install
  2. A new enviroment is created by pipenv: ~.local/share/virtualenvs/project1-12345678
  3. User runs: Pipes --link .
  4. Behind the scenes, Pipes will run pipenv --venv from the current location (.), and the result will be: ~.local/share/virtualenvs/project1-12345678
  5. The command output is written into a file ~.local/share/virtualenvs/project1-12345678/.project
  6. The .project file will help Pipes know what directory to cd into.
  7. User runs pipes project1
  8. Pipes resolves the environment by name, and looks for a .project file *
  9. 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.

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

@uranusjr
Copy link

uranusjr commented May 4, 2018

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

@gtalarico gtalarico added the enhancement New feature or request label May 7, 2018
@gtalarico gtalarico added this to the 0.6.0 milestone May 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants