Page MenuHomeSoftware Heritage

dev doc: source virtualenvwrapper.sh, as mkvirtualenv is gone from PATH
ClosedPublic

Authored by zack on Aug 23 2019, 4:19 PM.

Diff Detail

Repository
rDDOC Development documentation
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

olasd added a subscriber: olasd.

virtualenvwrapper has always been implemented as a set of shell functions to be sourced in your $shell_profile file, so I don't think the commit message is quite correct (as there's never been a mkvirtualenv command in anyone's PATH).

It's clear that the current instructions won't work when running all commands in succession (because virtualenvwrapper's config won't have been sourced unless the session has been restarted), so I guess this change is better than nothing.

All in all I think it would be better if the virtualenvwrapper setup was moved to a new paragraph, because the intent of this paragraph is to tell people to create a swh virtualenv and to enter it, not really to tell them how to set up virtualenvwrapper (which isn't mandatory as noted in the next paragraph).

This revision is now accepted and ready to land.Aug 23 2019, 6:38 PM
This revision was automatically updated to reflect the committed changes.
In D1910#44117, @olasd wrote:

It's clear that the current instructions won't work when running all commands in succession (because virtualenvwrapper's config won't have been sourced unless the session has been restarted), so I guess this change is better than nothing.

I hear you, and agree. I've proposed this change to have something that would work out of the box even for someone who has never used virtualenvwrapper (although, admittedly, only the first time; starting from the 2nd time they'll need to know how to properly set it up to get a working workon anyway…). I think it's better than nothing too, so I won't revert it. A dedicated paragraph about virtualenv only, pointing to appropriate general doc (any suggestion?) would indeed be better.