suggestion : replace virtualenv with python3 -m venv

[squalou]

Hi,

I'll do this in my local installation, and I think it would be a minor yet interesting change.

It would required one less '3rd party' dependency, or, to be fair : a dependency native to python 3.3+ and most of the time included with python when distributed. (and there are far less transitive dependencies than with virtualenv package)

Arch includes it in python3 package, debian-like have a python3-venv package.

Posting this here in case you think of a reason why not to proceed that I could have missed.

[squalou]

I have one additional required dependancy unfortunately on client : python3-dev, or else netiface wheel wont compile. Which in the end with transitive deps makes it roughly the same size.

Still, only 'regular' python tools. So, wondering.

[jikamens]

I'm happy to consider a PR for this change. I don't think either python3-venv or python3-dev are large enough to be a disk-space concern on the client.

[squalou]

So far it works but before submitting a PR I have optimizations to consider.

To be honest, I'm facing a weird pythonic situation, maybe you could help, at least help understand.

python3-netifaces is a package that exists, and is already installed (required by netwokmanager and the likes)

The package provides this :

/.
/usr
/usr/lib
/usr/lib/python3
/usr/lib/python3/dist-packages
/usr/lib/python3/dist-packages/netifaces-0.11.0.egg-info
/usr/lib/python3/dist-packages/netifaces-0.11.0.egg-info/PKG-INFO
/usr/lib/python3/dist-packages/netifaces-0.11.0.egg-info/dependency_links.txt
/usr/lib/python3/dist-packages/netifaces-0.11.0.egg-info/top_level.txt
/usr/lib/python3/dist-packages/netifaces-0.11.0.egg-info/zip-safe
/usr/lib/python3/dist-packages/netifaces.cpython-312-x86_64-linux-gnu.so
/usr/share
/usr/share/doc
/usr/share/doc/python3-netifaces
/usr/share/doc/python3-netifaces/README.rst.gz
/usr/share/doc/python3-netifaces/changelog.Debian.gz
/usr/share/doc/python3-netifaces/copyright

But, I don't know how to make use of this in a created venv.

When I try to build the vend with netifaces in requirements, it builds it (hence the python-dev package requirement)

Is this 'normal' ? isn't there a way to refer to system lib ?

With python-dev installed, everything ends up ok, with this in the venv

/var/client-venv                                                                                                  
$ find . | grep netiface                                                                                                                                                                     
./lib/python3.10/site-packages/netifaces.cpython-310-x86_64-linux-gnu.so
./lib/python3.10/site-packages/netifaces-0.11.0.dist-info
./lib/python3.10/site-packages/netifaces-0.11.0.dist-info/INSTALLER
./lib/python3.10/site-packages/netifaces-0.11.0.dist-info/LICENSE
./lib/python3.10/site-packages/netifaces-0.11.0.dist-info/zip-safe
./lib/python3.10/site-packages/netifaces-0.11.0.dist-info/METADATA
./lib/python3.10/site-packages/netifaces-0.11.0.dist-info/REQUESTED
./lib/python3.10/site-packages/netifaces-0.11.0.dist-info/RECORD
./lib/python3.10/site-packages/netifaces-0.11.0.dist-info/top_level.txt
./lib/python3.10/site-packages/netifaces-0.11.0.dist-info/WHEEL

[squalou]

answering to self - partly

looks like --system-site-packages in venv creation is a solution.

What would you think of this ? I don't know if it's an issue to 'break isolation' like this but anyway python runtime is on system, isn't it ?

[squalou]

EDIT. Looks like not to break everything there should be two requirements.txt, one without netifaces (requirements.txt) , the other one only netifaces (say requirements-system.txt) create venv with --system-site-packages

and then activate venv, and pip install --ignore-installed requirements.txt pip install requirements-system.txt

ALL this to prevent python-dev 30 Mo package, and be exposed to a system lib present or not, or evolve, or break, or be removed.

SO : I have my own answer, it's a very bad idea :)

I'll go with python3-dev dep.

PR will come as soon as tested

[squalou]

PR #49 open, tested on debian and mint, needs at least Arch testing first.

[squalou]

Tested with Arch, works fine. Indeed, all 'dev' things are included in python package so there's no additional requirement.