Debian/Ubuntu allow imports when not declared on setup_requires

[latot]

Hi all!, I'm too confused with this.

As I know, actually when you run a setup.py with import, this should be the default behavior:

#This will fails with no numpy module, in a try will trigger the catch
import numpy
setup(
  ...
  setup_requires(["numpy"]),
  ...
)
#This one will works fine
import numpy

In the case we try to import something before declare it in setup_requieres it should trigger that there is no module. I have checked this should be the default behavior on setuptools and in my system Gentoo 64 actually does that on venv.

But... for some reason, doing that on a Debian or Ubuntu distributions this behavior changes, and the imports are allowed without take in consideration setup_requieres.....

I'm very confused with that... can someone explain why plis?

Thx!

[abravalheri]

I am not sure if I understood your question/example. What is the "catch" that is being triggered?

I imagine that if you have an import statement in the beginning of the file and the package is not installed, the entire script should fail, right? Maybe the difference between the distros is the presence of numpy?

If you want to investigate that further could you please provide a complete (minimal) reproducer, including all the steps to reproduce the problem starting from scratch? If you can make it using a docker container as runtime that would be even better; otherwise a fresh virtual environment would be recommended.

Regardless, please avoid using setup_requires, instead the recommended way of dealing with build-time dependencies is via pyproject.toml's [build-system] requires = [...]. You can read more about it in https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/#build-time-dependencies.

I don't know if you are running python setup.py ..., but if that is the case, please avoid using setup.py as a executable script, it should only be seen as a configuration file. To build a distribution file for your package please prefer python -m build, and to install a package, please prefer pip install.

[latot]

Oks, lets do with step by step:

In Gentoo:

python -m venv pyenv
source pyenv/bin/activate
pip install numpy
mkdir a
cd a
nano setup.py

Write this:

from setuptools import setup

import numpy

setup()

Now:

pip install .

This fails with:

      ModuleNotFoundError: No module named 'numpy'

Which is fine, because there is no setup_requires and the import is before the setup statement.

While in ubuntu this happens:

Processing /tmp/a
  Preparing metadata (setup.py) ... done
Using legacy 'setup.py install' for UNKNOWN, since package 'wheel' is not installed.
Installing collected packages: UNKNOWN
  Running setup.py install for UNKNOWN ... done
Successfully installed UNKNOWN-0.0.0

is installed correctly.... I don't know why the differences...

In the first example:

pip list
Package    Version
---------- -------
numpy      1.25.0
pip        23.1.2
setuptools 67.8.0

In the second one:

pip list
Package    Version
---------- -------
numpy      1.25.0
pip        22.0.2
setuptools 59.6.0

I also try upgrading setuptools to 68.0.0, but was the same, the module was installed correcly.

Why is that difference?

[abravalheri]

How about using the same versions of pip + the same versions of setuptools in both distros? Have you tried that?

[webknjaz]

 Preparing metadata (setup.py) ... done
Using legacy 'setup.py install' for UNKNOWN, since package 'wheel' is not installed.

This means that pip does not use PEP 517 there at all. This is usually caused by an old pip. But since you said it'd Ubuntu, I'm going to bet that this is because of how they repackage pieces of CPython/virtualenv/pip/setuptools/ensurepip. Deb/ubuntu is known for this kind of behavior + they tend to use old versions and patch things out, unlike Gentoo.
And since in this case, the legacy install (that pip can't even track properly) is used, things like numpy leak from the external site-packages into the installer process. With PEP 517 in use, the build front-ends make isolated temporary build envs that don't have access to external import paths.

[webknjaz]

Note that the presence of pyproject.toml is usually treated as an explicit opt-in to use PEP 518 and PEP 517. You should normally just declare it. And don't forget to set an explicit build-backend: otherwise, build front-ends fall back to a legacy setuptools implementation, not the preferred one.

[webknjaz]

Ah, this pypa/pip#10717 is probably the reason for the fallback.

[latot]

Hi thx! and you are right, with the latest pip now I have the same behavior!

thx for the docs, now I'm be able to know why all this!