-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Make --relocatable even more relocatable #558
Comments
+1 |
@omribahumi have you started on this? Is there a reason those links aren't relative to start with? It's not clear if there's a firm reason why virtualenvs don't start off relocatable. |
@wickedgrey I wrote an external script to update the relevant files. I didn't want to maintain a fork of virtualenv. I see no reason not to make the links symbolic globally, as you said. We can add a new activate script though: activate.bash |
+1 |
1 similar comment
+1 |
Yes, the bash activate script should set However, as stated earlier, this doesn't concern Are there strong motivations against this change? |
Adding a reference to the newest issue #1067 related to this to help consolidate efforts on solving this half-decade old problem with the activation scripts. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions. |
Apparently even when running
virtualenv --relocatable
on my virtualenv, it's still not entirely relocatable:${VIRTUAL_ENV}/local
are absolute instead of symbolicVIRTUAL_ENV
environment variable defined inbin/activate
is hard-codedI'm thinking of fixing these myself, here's how I thought of doing it:
VIRTUAL_ENV="$( cd "$( dirname "${BASH_SOURCE[0]}" )/.." && pwd )"
Any thoughts?
Omri.
The text was updated successfully, but these errors were encountered: