Python virtual env on silverblue



So, just because it puzzled me a bit. I am doing python developement, and since python is already there, I just used a virtual env. Easy peasy, on python 3, that’s one command away:

python3 -mvenv /tmp/myvenv

But on a silverblue system, it result into that:

$     python3 -mvenv /tmp/myvenv
Error: Command '['/tmp/myvenv/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.

Digging further, I run the command:

$ /tmp/myvenv/bin/python3 -Im ensurepip --upgrade --default-pip 
Traceback (most recent call last):
  File "/usr/lib64/python3.6/", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib64/python3.6/", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/lib64/python3.6/ensurepip/", line 5, in <module>
  File "/usr/lib64/python3.6/ensurepip/", line 232, in _main
  File "/usr/lib64/python3.6/ensurepip/", line 111, in _bootstrap
    new_whl = rewheel.rewheel_from_record(dr,
  File "/usr/lib64/python3.6/ensurepip/rewheel/", line 75, in rewheel_from_record
    new_wheel.write(os.path.join(site_dir, f), arcname=f)
  File "/usr/lib64/python3.6/", line 1594, in write
    zinfo = ZipInfo.from_file(filename, arcname)
  File "/usr/lib64/python3.6/", line 496, in from_file
    zinfo = cls(arcname, date_time)
  File "/usr/lib64/python3.6/", line 338, in __init__
    raise ValueError('ZIP does not support timestamps before 1980')
ValueError: ZIP does not support timestamps before 1980

Digging even further, I found that venv try to create a wheel from installed packages, and those have a date in the past, because ostree generate reproductible images. I searched around, and stumbled on the following bug: . I couldn’t find more information, but I am going to ask around.

So I guess for now, my advice is to use venv in a container, since the venv generate on ostree is not functional, or rather do not have pip (due to the aformentioned issue), so slightly useful for my purpose of developing.


I’ve only used virtualenvs via virtualenvwrapper - does that work on Silverblue?


That’s likely, since that’s a wrapper. But again, using podman to create a container can sidestep the problem, and in fact, you do not even need the venv in the first place, since that’s already in a container, you can install system wide all kind of stuff since this is isolated from the system already.




Instead of using
python3 -m venv
I just did:
virtualenv-3 venv
and it worked !