On Thu, Oct 22, 2020 at 12:37 PM Vincent Bernat <ber...@debian.org> wrote:
> ❦ 6 octobre 2020 12:32 +03, Jyrki Pulliainen: > > > Now, python3.8-venv contains the ensurepip module. But to me it is very > > unclear if python3.8-venv is going to disappear? It also makes depending > on > > these packages generally a lot more brittle: I'd rather depend on > > python3-venv than python3.8-venv. We are not depending on the > > /usr/bin/pyvenv binary, but executing the module with "python -m venv", > so > > it does not matter if the python3-venv just drops the binary. > > > > Could you please clarify what is going to be removed, which packages are > > going to stay? > > From my understanding, only the pyvenv command will disappear. > > Doko, why is python3.x-venv a separate package? It seems `python3 -m > venv` doesn't work without the ensurepip module shipped in > `python3.x-venv`. > > python3-venv package was useful to pull the dependencies to get a > working venv module. Can we either keep the python3-venv as a > metapackage for this purpose and integrate back the ensurepip module > (300 bytes) into libpython3.x-stdlib? > > Thanks. > Hi all, I added a package to mentors that addresses the issue, albeit in a somewhat ugly way. Available here https://mentors.debian.net/debian/pool/main/d/dh-virtualenv/dh-virtualenv_1.2.2-1.dsc The change in question is doing some trickery in the debian/rules file on figuring out which Python version we are running at build time (which can probably backfire in some cases), and would indeed want that metapackage instead :) - Jyrki -- - Jyrki
