Associate project dir with new virtual environment

[meshy]

This adds a flag to pew that lets it know which directory to switch to when activating an environment with pew workon foo.

I really miss this feature from virtualenvwrapper, and I'd love still use this workflow, so if I've gone about this the wrong way, please let me know, and I'll see what I can do to make it right.

This fits the workflow I'm used to, but I understand it might impact other people's workflows.

Because of that, this may be blocked waiting for the PR on pew to add an option to prevent the directory changing when running pew workon, as that will offer a way to restore the existing behaviour.
Update: That's been merged now.

I wasn't sure where to add tests for this particular functionality, but I'm not entirely familiar with pytest, so I might have missed something.

If there's a place you think is appropriate for the tests, or a better way to achieve this, please let me know.

[techalchemy]

Hey @meshy thanks for putting htis together, sorry for the delay! We had some issues with our testing infrastructure recently and we are just getting that sorted. Once that's straightened out I'd say we can merge this as a bolt-on for now. We can sort out the testing bit if we ever actually build out the feature in pipenv.

/cc @pfmoore #1824

[meshy]

Hey @techalchemy, no worries on the delay :)

I'm delighted you're happy with the concept of merging this. Thanks very much!

[techalchemy]

plz update onto master and we can resume work

[meshy]

No worries. I've just rebased, and repushed.

[uranusjr]

Closing in favour of Pipes for the moment. Take a look! #1824 (comment)

[meshy]

Thanks for pointing me in the direction of Pipes -- it does look very nice, but I'm concerned about moving to a project that's only a little over a day old. I'll keep an eye on it though.

At the moment, my work-around for this is to make the following call immediately after creating the virtualenv:

# Create the venv.
pipenv install --three

# Work-around for https://github.com/pypa/pipenv/pull/1861
echo $(pwd) > $(pipenv --venv)/.project

[meshy]

FWIW, this PR solves the issue that the Pipes author mentions in their follow-up tweet.

The --link approach is kind of nasty but I could not think of another way to detect & tie envs to project dirs.

It would be helpful if pipenv stored the project path or provided a way to resolve it
https://twitter.com/gtalarico/status/991908875371675648

[erinxocon]

@meshy can you pull from master and rebase?

[meshy]

@erinxocon rebased :)

[uranusjr]

The tests failures are unrelated, but I think it’s best to fix them first before merging. We can’t have a release until everything’s back working anyway…

[gtalarico]

FWIW, this PR solves the issue that the Pipes author mentions in their follow-up tweet.
The --link approach is kind of nasty but I could not think of another way to detect & tie envs to project dirs.

Hi @meshy - How would this PR solve the issue?
Pipes needs a way to resolve - from a pipenv folder - which project directory the env was created from.
Would these additional pew flags create a .project file in the env folder?

[meshy]

@gtalarico Hey!

Will the additional pew flags create a .project file in the env folder?

Yes, exactly :)

[meshy]

Thanks!