Add --here option for pew workon to prevent current directory to be changed

[AlexandreDecan]

This PR implements #179.

It adds an optional argument for pew workon (--here) that prevents the current directory to be changed.

[berdario]

Thank you

What is the use case? If you created the venv yourself, probably you can simply avoid creating it as a project if you don't want the cd functionality

I guess this could be useful if you're working on a shared machine, but I fail to see exactly the need for this.

Also, I haven't checked, but I think that pew in environ $SHELL would already not automatically cd

[AlexandreDecan]

Basically, this PR allows the workflow "cd into the right directory; then enable venv with no cd" where one had to follow "enable venv with cd; cd into the right directory". As, most of the time, I first open a terminal in the right directory and then I enable the environment, I thought it could be interesting to add this option to pew workon.

Another way of seeing this PR is to consider it as a way to allow a "default path" for a venv, with an easy way to reuse a single venv for different purpose.

[berdario]

Sorry, I haven't merged this yet.

I still feel a bit wavering about this, I hoped that in the last couple of weeks someone would chime in and give his perspective on this, if they'd think this would be useful or not.

[AlexandreDecan]

No problem, I understand;)

[meshy]

FWIW, I'd like this.

At the moment, when pipenv creates environments, it uses pew under the hood, but it doesn't pass -a $(pwd). I'm hoping to create a PR to remedy this soon, but I'm concerned that I will (justifiably) get push-back from their end, because it would mean that pew workon myproject would have different behaviour as a result.

Having this flag available on pew would mean that I would be able to offer an alternative workflow to pipenv when I suggest the change.

[berdario]

I see, this makes sense.

Thinking more about it, while the project/-a feature can be useful, I'm now wondering if this was actually a good idea: have some non-obvious (since it wouldn't be in a centralized place, but rather a file in every virtualenv) configuration that changes the default behavior of the tool.

Rather than having a flag to restore the default behavior, maybe it would've been better to have a --cd flag that would allow people to opt-in, whenever they'd want to cd into the preselected project directory.

Alas, the choice has been made (mostly because pew started just as a virtualenvwrapper reimplementation) and breaking compatibility for something like this is an even worse idea

[meshy]

I think you're right. Ideally, the --cd option would be saner.

It's pretty late for me, so this might just be me sleep-typing, but I have an idea that might work:

We could transition to this better behaviour by always creating an extra file in the virtual environments (eg: .pew, as well as .project).

When .project is found, we would know that -a was passed, and always change directories.

Otherwise, when --cd is passed, we could switch to the path in .pew.

Oh, and .pew probably isn't a good name for the file.

[meshy]

Actually, thinking about it more, in light of pypa/pipenv#1824, perhaps it would be of use to populate a single file in $WORKON_HOME with all the venvs and any associated config.

[meshy]

There is another possible advantage to having a new file format for this information (a single-file or one-per-project doesn't matter) -- each project could individually configure if it should switch by default.

I have no idea if that's something people would use though.

[berdario]

Yup, anyhow let's stick to the minimal implementation for now.

I merged it, and just added a couple of TODO notes and tests