problem with add2virtualenv

[Google Is Evil]

Hi!

I wanted to maintain a set of frequently used Python packages and add them to project-based virtualenvs.

So I created a virtualenv 'common' to maintain all those common packages.

I also adjusted the postmkvirtualenv hook as follows:

-------------------

#!/bin/zsh
# This hook is sourced after a new virtualenv is activated.


PROJECTS_HOME=${PROJECTS_HOME:=z}

D="$HOME/${PROJECTS_HOME}"
PY="3.7"

proj_name=$(basename $VIRTUAL_ENV)
mkdir $D/$proj_name
add2virtualenv $D/$proj_name
add2virtualenv $WORKON_HOME/common/lib/python$PY/site-packages

cd $D/$proj_name

setvirtualenvproject

git init

-----------------

That looks fairly obvious, and I can eg. say "workon abc" to start working on the project 'xyz', and then access packages which I have installed in 'common'.

But any attempt to use pip while 'xyz' is active, fails with a traceback.

(xyz)$ pip
Traceback (most recent call last):
  File "/home/debian/.virtualenvs/xyz/bin/pip", line 6, in <module>
    from pip._internal import main
  File "/home/debian/.virtualenvs/common/lib/python3.7/site-packages/pip/_internal/__init__.py", line 40, in <module>
    from pip._internal.cli.autocompletion import autocomplete
  File "/home/debian/.virtualenvs/common/lib/python3.7/site-packages/pip/_internal/cli/autocompletion.py", line 8, in <module>
    from pip._internal.cli.main_parser import create_main_parser
  File "/home/debian/.virtualenvs/common/lib/python3.7/site-packages/pip/_internal/cli/main_parser.py", line 7, in <module>
    from pip._internal.cli import cmdoptions
  File "/home/debian/.virtualenvs/common/lib/python3.7/site-packages/pip/_internal/cli/cmdoptions.py", line 24, in <module>
    from pip._internal.models.search_scope import SearchScope
  File "/home/debian/.virtualenvs/common/lib/python3.7/site-packages/pip/_internal/models/search_scope.py", line 11, in <module>
    from pip._internal.utils.misc import normalize_path, redact_password_from_url
  File "/home/debian/.virtualenvs/common/lib/python3.7/site-packages/pip/_internal/utils/misc.py", line 58, in <module>
    from typing import cast, Tuple
  File "/home/debian/.virtualenvs/common/lib/python3.7/site-packages/typing.py", line 1357, in <module>
    class Callable(extra=collections_abc.Callable, metaclass=CallableMeta):
  File "/home/debian/.virtualenvs/common/lib/python3.7/site-packages/typing.py", line 1005, in __new__
    self._abc_registry = extra._abc_registry
AttributeError: type object 'Callable' has no attribute '_abc_registry'

I'm on Debian Buster, with Python 3.7.3 and virtualenvwrapper 4.3.1.

What gives?

[Doug Hellmann]

Have you tried just having postmkvirtualenv install those common packages into each new virtualenv? That would be more like what I would expect, where each environment is isolated but the hook script “primes” them with a common set of utilities. That might also solve the import issue with pip, which is pulling the executable from one virtualenv but getting the supporting modules from another.

Doug

--
You received this message because you are subscribed to the Google Groups "virtualenvwrapper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtualenvwrap...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualenvwrapper/f4335bae-cc1e-4741-902d-a82925c08a29%40googlegroups.com.

[Linux Python]

Hi Doug!

No, I haven't tried that. My objective was to save setup time and,
more importantly, disk space. Otherwise I could just have eg. copied a
canned requirements.txt and pip install'ed that from the hook. I mean,
what's the intended use case for add2virtualenv, after all?

Thanks,
T.

> To view this discussion on the web visit https://groups.google.com/d/msgid/virtualenvwrapper/8A9EA6EB-CC27-4695-9A4C-420AD122FF6A%40doughellmann.com.

[Doug Hellmann]

The idea for add2virtualenv is to add a directory with packages in it, but not necessarily the site-packages directory of another virtualenv. Something like the source directory from a version control repository or a global directory created by using the --root option to pip install.

> To view this discussion on the web visit https://groups.google.com/d/msgid/virtualenvwrapper/CAFU9xChqJKwk5SOTtWp_k9S7xmAf%3Dc%3Dty7AmdsKa7zNUTRg28A%40mail.gmail.com.

[Linux Python]

I thought that was the natural way to manage those other collections
of packages - in their own virtualenv, using that as a container. I do
install the packages there with pip and the correct version of Python,
so. I'll experiment a bit with that, then.

Thank you!

> To view this discussion on the web visit https://groups.google.com/d/msgid/virtualenvwrapper/0DBE6E4D-03F6-455A-A8B8-8DE767187C57%40doughellmann.com.