Python is built without LZMA support in Codespaces default image

[hkratz]

Python 3 is built with LZMA support in all commonly-used Linux distributions so it is commonly expected to be available.

Impact: This causes the build to fail when trying to follow unmodified build instructions for Rust.

• Reproduces in: Codespaces
• Name of Dev Container Definition with Issue: codespaces-linux

Steps to Reproduce:

1. In the Terminal window run: python3 -c 'import tarfile; tarfile.open("/tmp/abc.xz", "w:xz")'

Result:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/codespace/.python/current/lib/python3.10/tarfile.py", line 1642, in open
    return func(name, filemode, fileobj, **kwargs)
  File "/home/codespace/.python/current/lib/python3.10/tarfile.py", line 1746, in xzopen
    raise CompressionError("lzma module is not available") from None
tarfile.CompressionError: lzma module is not available

Expected result: no error

[bamurtaugh]

cc @joshspicer @edgonmsft

[ericLemanissier]

I was bitten by this too. Another more fundamental way to test is to do python -c "import lzma" which gives

Traceback (most recent call last):
 File "<string>", line 1, in <module>
 File "/opt/python/3.10.4/lib/python3.10/lzma.py", line 27, in <module>
   from _lzma import *
ModuleNotFoundError: No module named '_lzma'

[joshspicer]

Thanks for the report! I'll play around with it. If either of you have steps to solve these, please do share.

[ericLemanissier]

it is usually solved by installing libzma-dev before building python

[joshspicer]

Interesting, it looks like we do: https://github.com/microsoft/vscode-dev-containers/blob/ac5cb52fc10ad9170beccc58b1021d5bb8af6b37/script-library/python-debian.sh#L282-L284

[joshspicer]

Ah, this build of python is coming from an upstream oryx image we use, which would be built with some set of libraries they control, not the libraries we include in that script above. We are moving away from using the upstream image in the near future (to have greater control in instances like this). I've put up a PR (https://github.com/microsoft/Oryx/pull/1424) on the Oryx repo to address this.

In the meantime, a quick workaround would be to use our python published image: mcr.microsoft.com/vscode/devcontainers/python.

[joshspicer]

We have a couple solutions in the works, just a matter of which one will land first 😄 . In the meantime the workaround I previously posted is the best way to get around this bug

[joshspicer]

a workaround is now published