Mariner 1.0's Python lacks built-in module `xml`

[jiasli]

Mariner 1.0's Python doesn't have the built-in module xml (https://docs.python.org/3/library/xml.html) by default:

> docker run -it --rm cblmariner.azurecr.io/base/core:1.0 python3 -c 'import xml'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'xml'

It has to be installed by dnf install python3-xml. This issue doesn't exist on other Linux distributions. I am not sure if this is by design or a bug.

Mariner 2.0 doesn't have this problem:

> docker run -it --rm mcr.microsoft.com/cbl-mariner/base/core:2.0
# tdnf install -y python3
# python3 -c 'import xml; print(xml.__file__)'
/usr/lib/python3.9/xml/__init__.py

This causes failure for Azure CLI package (https://github.com/Azure/azure-cli/issues/23266). We definitely don't want to add python3-xml in our RPM spec file solely for Mariner 1.0:

https://github.com/Azure/azure-cli/blob/99731afbb5d2b01488bb0480c7e6e662597e041c/scripts/release/rpm/azure-cli.spec#L31

Requires:       %{python_package}

[eric-desrochers]

We reduced our size footprint in Mariner 2.0 by reducing the numbers of packages in the base container image. I would recommend you add a Requires: python3-xml (runtime dependency) in your SPEC file instead of relying on Mariner to provide pre-installed packages.

[jiasli]

We reduced our size footprint in Mariner 2.0 by reducing the numbers of packages in the base container image. I would recommend you add a Requires: python3-xml (runtime dependency) in your SPEC file instead of relying on Mariner to provide pre-installed packages.

This issue only happens in Mariner 1.0. Mariner 2.0's Python has xml. Shouldn't Mariner 1.0 and 2.0 have the same config?

I would recommend you add a Requires: python3-xml (runtime dependency) in your SPEC file instead of relying on Mariner to provide pre-installed packages.

We don't want this special logic solely for old deprecated Mariner 1.0. 😉

[eric-desrochers]

Sorry I was distracted for a minute, I unintentionally inverted the version for a second, despite I knew it is impacting only Mariner 1.0.

Regardless of the Mariner version, I still believe you should add a Requires: python3-xml (runtime dependency) in your SPEC file instead of relying/assuming that Mariner will provide your runtime dependencies pre-installed in the image. You don't have to add this Requires only for Mariner 1.0 binary package, you can add it and keep it for both.

Package manager (dnf, tdnf,) is smart enough to detect if the dependencies is already installed or not.

[oliviacrain]

@jiasli Thanks for the feedback. Totally agree- it's a pain to not have all of the built-in modules, and it violates the principle of least surprise. This split of the built-in xml module from the rest of the built-in libraries stems from the spec's origin in Photon. This weirdness has been enough of an issue that we folded the python3-xml package into python3-libs for 2.0.

Just as you don't want to add logic solely for "old deprecated 1.0", we want to avoid change for 1.0 since it's in a fairly stable state (1.0 is nearly two years old now).

I think we can both be happy here: You can add python3-xml as a dependency for both 1.0 and 2.0 and avoid special-casing. We configured our python3-libs package in 2.0 such that tdnf and dnf will recognize that python3-xml is fulfilled by python3-libs. You can drop the requirement once 1.0 is no longer supported by your product.

Would this arrangement work for you?

[eric-desrochers]

@oliviacrain I believe packages should always declare all their runtime dependencies relationship (e.g., python module import, ...) and not counting on the OS to have it installed.

It should always contain the list of packages that must be installed for a given program in the binary package to work.

[jiasli]

This split of the built-in xml module from the rest of the built-in libraries stems from the spec's origin in Photon. This weirdness has been enough of an issue that we folded the python3-xml package into python3-libs for 2.0.

We hit it too! 🤣

Package manager (dnf, tdnf,) is smart enough to detect if the dependencies is already installed or not.

Other Linux distributions don't have python3-xml at all. In this case, we will need a special SPEC only for Mariner.

Red Hat:

> docker run -it --rm registry.access.redhat.com/ubi8/ubi:8.4 bash
[root@ed929244d4a0 /]# dnf install python3-xml
...
Error: Unable to find a match: python3-xml

Debian:

> docker run -it --rm debian:11
root@4d2cc3521fe6:/# apt update
root@4d2cc3521fe6:/# apt install python3-xml
...
E: Unable to locate package python3-xml

I think Mariner 1.0 should be consistent with Mariner 2.0 as well as other Linux distributions.

[jiasli]

We configured our python3-libs package in 2.0 such that tdnf and dnf will recognize that python3-xml is fulfilled by python3-libs.

I totally understand. I am only thinking maybe we should backport this fix to Mariner 1.0? Even though Mariner 1.0 is deprecated, it is still used as the base image of other images, such as mcr.microsoft.com/dotnet/aspnet:6.0-cbl-mariner1.0 (https://github.com/Azure/azure-cli/issues/23266).

[christopherco]

Mariner 1.0 is EOL. Closing this issue out as part of resolving out stale issues. Please open a new issue against 2.0 if this still a problem