Incompatible with virtualenv v20

[danpalmer]

Virtualenv has just released version 20, which breaks compatibility with dh-virtualenv.

Specifically, dh-virtualenv still passes the --no-site-packages option which has been deprecated for a while now. v20 now rejects this argument.

There may be other issues as well, but this one was what we noticed first so we've reverted to v16, the previous release. v20 is a full rewrite so more testing may be required.

[jhermann]

The recommendation is to use --builtin-venv by now, unless you dabble with old stuff. That avoids the problem altogether.

Still, the deprecated option should be removed.

[danpalmer]

@jhermann on Debian the --builtin-venv option requires an additional package to be installed on the system, the python3-venv package I believe. If this is the recommended use, should this package depend on that package so that it's present? I also didn't notice that recommendation in the docs although I must admit I was reading very quickly to try to figure out why our build broke this morning!

[jhermann]

Well, the general direction is to use venv with 3.4+ projects.

And a [Build-]Depends belongs into YOUR control file, as soon as you use the venv option.

[nailor]

dh-virtualenv already depends on virtualenv | python-virtualenv (>= 1.7) | python3-venv, which covers the python3-venv. In any case an additional package is required, wether it is virtualenv or python3-venv.

Now, the v20 is going to cause issues to people once that starts rolling out to people's systems. Solution here would probably just dropping the --no-site-packages flag. It has been deprecated for (at least) 6 years in virtualenv. Pull requests appreciated 😊

[danpalmer]

Interesting. When we switched over to the built in venv with --builtin-venv we got an error message saying that package was required. We could be on a slightly older version of dh-virtualenv though.

[jhermann]

@danpalmer add --upgrade-pip --preinstall "setuptools>=38" --preinstall "wheel" to isolate against smelly or incomplete environments.

[danpalmer]

Thanks, we've actually pinned virtualenv==16.7.9 in our build environment and that worked fine.

[nailor]

@danpalmer So the notation for dh-virtualenv's dependencies means that any of those satisfies it. If you have virtualenv already, it won't pull python3-venv. That's what @jhermann also meant by controlling your Build-Depends, i.e. use those to make sure the right implementation is installed.

[jhermann]

Situation regarding relevant options:

$ virtualenv --help
…
  --setuptools          DEPRECATED. Retained only for backward compatibility. This option has no effect.
  --distribute          DEPRECATED. Retained only for backward compatibility. This option has no effect.
  --unzip-setuptools    DEPRECATED.  Retained only for backward compatibility. This option has no effect.
$ virtualenv --version
16.7.9
$ virtualenv --help
…
  --pip version                    pip version to install, bundle for bundled (default: latest)
  --setuptools version             setuptools version to install, bundle for bundled (default: latest)
  --wheel version                  wheel version to install, bundle for bundled (default: latest)
$ virtualenv --version
virtualenv 20.0.4

So --setuptools was reintroduced but with an argument – means this option should be avoided altogether.

I'd recommend against using the new options, we have --preinstall to control versions and that works with both variants.

[jhermann]

The ultimate quick-fix solution is to remove --setuptools from your rules if you encounter the error (removing it from dh-venv code would break OLD virtualenv versions) – add that to docs / trouble-shooting. 2nd part: add --use-system-packages, so a supported option is injected until the above fix is released – and that is a dirty hack, #294 should be released ASAP.

Or else just use builtin venv if you can.

Proper fix:

• add a --virtualenv «pip-spec» option so that you can determine the version used – questionable insofar venv avoids all this, is it still worth it?
• generally, put command line patterns as string-templates (.format()) into /etc/default/dh-virtualenv, and optionally take formats from the environment. Rewrite code to use those to generate command lines (using shlex to parse the strings). This would allow more control over the ever-changing tool calls. Should be forked into its own issue when pursued.

[eglobetrotter]

Same issue here running on Ubuntu 18.04.4 LTS, I have tried to use buildin venv by installing python3-venv, but it was not working because my current python is 3.7.5 and the buildin (python3-venv) is 3.6.7, even installing python3.7-venv didn't help. So my solution was (a dirty one) just to comment the line with argument "--no-site-packages" append in the deployment.py file (/usr/lib/python2.7/dist-packages/dh_virtualenv/deployment.py).
Looking forward to a fix.

My proposal is to check the version of virtualenv and then decide whether to append "--no-site-packages" or not.

[vladislavkoz]

The recommendation is to use --builtin-venv by now, unless you dabble with old stuff. That avoids the problem altogether.

Still, the deprecated option should be removed.

You saying that it is better to use --builtin-venv. I've switched to it from --with python-virtualenv but now I see that my package.deb file is too small(5Kb) and after installation, it doesn't create a new folder in the venvs folder in my system(Ubuntu 18.04), Did I miss something? Do I need to run python -m venv manually somewhere to add venv to package_name.deb file?? Can you help me?

Probably I have to use it in pair like the following version? [debian/rules]

#!/usr/bin/make -f

#DH_VERBOSE=1

EXTRA_REQUIREMENTS=--preinstall "setuptools>=34" 
DH_VENV_ARGS=--with python-virtualenv $(EXTRA_REQUIREMENTS)

%:
   dh $@ ${DH_VENV_ARGS}

override_dh_virtualenv:
   dh_virtualenv --python python3 --builtin-venv ${EXTRA_REQUIREMENTS}

[nailor]

Hi, You need both flags: --with python-virtualenv and the --builtin-venv First one tells dh to use dh-virtualenv for packaging and seconds is an argument to dh-virtualenv

On Wed 16. Mar 2022 at 12.48, vladislavkoz ***@***.***> wrote: The recommendation is to use --builtin-venv by now, unless you dabble with old stuff. That avoids the problem altogether. Still, the deprecated option should be removed. You saying that it is better to use --builtin-venv. I've switched to it from --with python-virtualenv but now I see that my package.deb file is too small(5Kb) and after installation, it doesn't create a new folder in the *venvs* folder in my system(Ubuntu 18.04), Do I miss something? Did I miss something? Do I need to run *python -m venv* manually somewhere to add venv to package_name.deb file?? Can you help me? — Reply to this email directly, view it on GitHub <#293 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAPRSE44FARCHED4YXUQPDVAG37TANCNFSM4KSL5PPQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

-- - Jyrki

[vladislavkoz]

Hi, You need both flags: --with python-virtualenv and the --builtin-venv First one tells dh to use dh-virtualenv for packaging and seconds is an argument to dh-virtualenv
On Wed 16. Mar 2022 at 12.48, vladislavkoz @.> wrote: The recommendation is to use --builtin-venv by now, unless you dabble with old stuff. That avoids the problem altogether. Still, the deprecated option should be removed. You saying that it is better to use --builtin-venv. I've switched to it from --with python-virtualenv but now I see that my package.deb file is too small(5Kb) and after installation, it doesn't create a new folder in the venvs folder in my system(Ubuntu 18.04), Do I miss something? Did I miss something? Do I need to run python -m venv manually somewhere to add venv to package_name.deb file?? Can you help me? — Reply to this email directly, view it on GitHub <#293 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAPRSE44FARCHED4YXUQPDVAG37TANCNFSM4KSL5PPQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.>
-- - Jyrki

Yes, thanks. You are absolutely right