virtualenv relocatable — does it really work [duplicate]

Question

This question already has answers here:

Renaming a virtualenv folder without breaking it (12 answers)

Closed 4 years ago.

I kept looking for answer but didn't find one. I have a virtual env dir, a project dir with a req.txt. When I run pip -r req.txt, it installs some apps from github (source) and some from pypi. The ones from pypi are fine after relocatable call on the virtual evn, however the links in the site-packages for the apps that it installed from github still point to the old directory location.

Anyone else has seen this behavior? Any quick way around it? Also, relocatable is not honoring the --no-site-packages flag that was used on the virtualenv originally. Once you move the virtual and reactivate it, everything is visible from the system's site-packages. Docs indicates this behavior as a fact, so I am wondering if there is any quick way around this?

Answer 1

As stated in the documentation --relocatable is an experimental option, so it's not surprising you are having difficulties with it. That said, did you remember to re-run --relocatable after installing new packages? If you installed the packages from github with -e, that might be an issue, as it doesn't install into site-packages, but symlinks into it. As an alternative to using --relocatable, you can usually erase the virtualenv-specific files and recreate it in place (which I've done a couple times when switching between platforms).

Answer 2

No, for one '--relocatable' does not update 'virtualenv/bin/activate' script. Yes you can fix that by re-running virtual env setup as zeekay suggested, however that stills fails to import any 'pip -e git ...' installs which are placed in 'virtualenv/src' so you will have to re-run those pip installs manually.

As I have gained experience as a developer I now avoid additional layers of dependency and abstraction which just have a tendency to be points of failure.

So now I don't install with pip editable (-e) and if needed manually clone repositories into 'project/src/' as opposed to 'project/virtualenv/src' and have the below auto_prep_pythonpath.py script loaded prior to launching my project (I reference it in my django.wsgi script).

As a side note I append 'tailored' to any packages placed in 'project/src' that are modified/hacked so this way I don't have to worry about backward compatibility and I track all source under code control as online repositories can and will brake on you.

Hope this helps.

"""
Prepares python path to include additional project/src/<APP> in PYTHONPATH - This file gets automatically loaded by projects __init__.py

This script lives in 'project/src/django-project/auto_prep_pythonpath.py', modify 
'SOURCE_ROOT' if you place it somewhere else.
"""
import logging
import os
import sys
SOURCE_ROOT = os.path.dirname(os.path.abspath(__file__)).replace('\\','/') # the replacements are when on windows
SOURCE_ROOT = os.path.join(SOURCE_ROOT, '../').replace('\\','/') 
SOURCE_ROOT = os.path.normpath(SOURCE_ROOT)

logger = logging.getLogger(__name__)

logger.info("Adding packages in 'src/*' required by project to PYTHONPATH.")
dirlist_arr = os.listdir(SOURCE_ROOT)
while dirlist_arr:
    item_path = os.path.join(SOURCE_ROOT, dirlist_arr.pop()).replace('\\','/') # replace dashes is for win based file system
    if os.path.isdir(item_path):
        if not item_path in sys.path:
            sys.path.insert(0, item_path) # we use insert to take precedence over any global paths - minimizes import conflict surprises
        logger.debug("Path '%s' added."  % item_path)