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

deactivate.bat doesn't cd back to %_LAST_DIR% #50

Open
thepacketgeek opened this issue Feb 25, 2015 · 4 comments
Open

deactivate.bat doesn't cd back to %_LAST_DIR% #50

thepacketgeek opened this issue Feb 25, 2015 · 4 comments

Comments

@thepacketgeek
Copy link

In cdvirtualenv.bat, there is logic setting %_LAST_DIR% to the current directory, but nothing in deactivate.bat to change back to the %_LAST_DIR% before activating.

Before I fork/MR, is this expected behavior for some reason?

Thanks!

@utek
Copy link
Collaborator

utek commented Feb 25, 2015

I'm ok with both versions. Not cd (as it is now) and cd to first dir as you propose. Maybe do it on option or some env variable (like VENV_CD_BACK or something). Anyway. Looking forward for PR if you'll think about something.

@thepacketgeek
Copy link
Author

Great, I like your idea of having options as well. I'll work on this soon.

@thebjorn
Copy link
Collaborator

I'm a big -1 on this. It's surprising and annoying to be pulled from your flow, e.g.:

\> workon py27
(py27) \> cd my\source
(py27) \my\source> :: fix something / test something
(py27) \my\source> workon py35
(py35) \my\source> :: fix something / test something
(py35) \my\source> deactivate
\my\source> :: maybe run tox or work on docs in global sphinx..

if I got tossed back to \ after deactivate I would find it surprising and unwelcome. cd-.bat mostly does what is asked here - except for the %_LAST_DIR% being continually clobbered. We could fix this by either appending to %_LAST_DIR% instead of overwriting, or by using pushd and make cd- a synonym for popd.

@thebjorn
Copy link
Collaborator

deactivate.bat is not our file (although this might be changing -- see my comment on PR #73), making this difficult. This issue should stay open until our version of deactivate comes so we don't forget.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants