1

I needed python3.7 for a project and it wasn't available as a ubuntu package, so I bootstrapped a python3.7 environment using conda. From that 'grandparent' environment, I created a 'parent' python3 virtual environment for the specific project.

From the parent environment in my project, I'm running a command line tool from the google-cloud-sdk which creates another test environment. That script creates a 'grandchild' environment by calling something equivalent to (parent) $ python3 -m venv /tmp/grandchild.

That grandchild environment doesn't have the pip binary installed, for some reason or another. And this is the problem. This missing pip causes the google script to fail to install dev-test dependencies. The parent, and the child do have pip installed, however, but pip doesn't get passed down.

When I take conda out of the picture, and rely only on the python that ships with my ubuntu package system (under /usr/lib), I can nest my virtual environments ad nauseam, and pip always seems to get inherited properly. I think this is something specific to python/pip conda environments that I'm tripping on.

I think this is a separate cause problem to this: pip missing from Python venv (I don't have that file ~/.pydistutils.cfg anywhere on my box)

UPDATE:

I've found a way to reliably repro this, and without the need for conda. This happens when the parent is created with virtualenv, i.e. virtualenv parent, and the child gets created from that parent using -m venv, i.e. (parent) $ python3 -m venv child. The child then doesn't get pip copied into it.

Nesting environments created with virtualenv works fine, and nesting environments created with venv works well too, but not when venv is used within a virtualenv-created environnment. They don't mix.

Note: environments don't really "nest" per-se, they are independent copies. I mean that one is created from the other.

init_js
  • 4,143
  • 2
  • 23
  • 53
  • What does this have to do with conda? Conda and venv are two separate solutions. If you want a conda environment, use conda. If you want a venv, use venv. – darthbith Jul 09 '19 at 00:22
  • I can see how that's misleading. I initially created a python3.7 environment with conda (3.7 doesn't ship by default in my ubuntu release). From that conda python 3.7 environment, called "python3 -m venv my_project" to make a project virtual environment. That project virtualenv behaves differently than one created with my ubuntu's default python, namely that environments created _from_ it are broken. The conda thing might be a red herring. Most likely not a bug with conda itself, but there's something different with the way the environments are created anyway. – init_js Jul 09 '19 at 00:30
  • My suggestion is not to do that. Just create a conda environment. Conda and venv are not made to mix together. – darthbith Jul 09 '19 at 00:39
  • it's not ideal, agreed. I added more details why pip was needed. after some testing I can report that this is unrelated to conda (I took the tag out from the list). It has more to do with calling `python3 -m venv` from an environment created with python-virtualenv. – init_js Jul 09 '19 at 01:30

1 Answers1

0

One workaround is to create all the environments with the same method.

e.g. use python3 -m venv for all environments along the chain.

  1. python3 -m venv parent; source parent/bin/activate
  2. (parent) $ python3 -m venv child

If that seems to tangle you into a web of symlinks, you may also provide the --copies flag: python3 -m venv --copies …, which can avoid that.

init_js
  • 4,143
  • 2
  • 23
  • 53