If you want to push a little further. Often when you build an extension which statically or dynamically link another library. You will need to use the same compiler. Otherwise you might bump into ABI comptability issues.
So do you plan on "managing" which version of GCC or g++ people have and issue a warning if they don't have the good one? How are you even supposed to find out? Many library will expose a flag that tells you which compiler version or range of version can be used. But no standard on this matter...

Don't get me wrong would be awesome if it worked. I just don't see a way to handle all these contraints ...

Jonathan 



---- On ven., 07 août 2020 10:28:50 -0700 David Mathog<dmathog@gmail.com> wrote ----

> Unfortunately, successfully building C libraries is way, way more
> complicated than that. There are nearly as many ways to detect and
> configure C libraries as there are C libraries; tools like pkg-config
> help a bit but they're far from universal.

Agreed that building a library is more complicated. (Building a
library, or anything for that matter, which depends on boost is even
worse.) Nevertheless, to do so the information provided by pkg-config
will always be required. It might not be sufficient, of course. As
for looking up this information, I am only aware of pkg-config and
pkgconf, and on many systems one is just a soft link to the other.
That is also what is used on Windows within Mingw. So it would not be
unreasonable to specify that this is the source of the information in
all Posix environments.

> There can be multiple versions of libpng on the same system, with different ABIs.

Requires-External supports version ranges and pkg-config will show the
version which is installed. If Requires-External is to ever have a
real usage presumably it would have to be compatible with pkg-config
in Posix environments. That is, how would it ever work otherwise?
Users who have placed pc files in odd locations would have to modify
PKG_CONFIG_PATH before running pip
or these would not be found. They would also have to specify
"libname" or "libname2", as appropriate, in some cases.

> doesn't even know what compiler the package will want to use (which
> also affects which libraries are available).

I had wondered about that. In the spec it has an example:

Requires-External C

which seems to be a requirement for a C compiler, but if it does not
specify which one, then the test could pass if it finds the Intel
compiler even though setup.py only knows how to build with gcc. Or
vice versa.

> day, the only thing pip could do with this information is print a
> slightly nicer error message than you would get otherwise.

In the case that started this thread a simple "The igraph library is
required but not installed on this operating system" and then exit
would have saved a considerable amount of time. So while it isn't
much, it is more than we have currently.

> What pip *has* done in the last few years is made it possible to pull
> in packages from PyPI when building packages from source, so you can
> make your own pkg-config-handling library and put it on PyPI and
> encourage everyone to use it instead of reinventing the wheel. Or use
> more powerful build systems that have already solved these problems,
> e.g. scikit-build lets you use CMake to build python packages.

I think that is what happened this time, but there was no test to see
if the package it built could be installed where it wanted to put it,
so it failed. At least I think that is what happened. In any case,
it did pull igraph down from PyPI but the installation failed.

One other point about "Requires-External" - as described, it lacks a
special case "none". (None really means "just the python version
which is running pip".) That is, there is currently no way to
distinguish between "this package has no external requirements" and
"the external requirement specification is incomplete". This
information really should be mandatory, even if it is just to tell a
person what must be installed in the OS before running pip. One can
imagine a utility analogous to "johnnydep" which would traverse a
proposed package install and verify that all the Requires-External
entries are in fact satisfied, or minimally, just list them. Pip
should warn when no "Requires-External" entries are present, and
"Requires-External none" would always suppress that warning.

Regards,

David Mathog
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-leave@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/archives/list/distutils-sig@python.org/message/BMLRH2JXM2B5EQAJ5NA44LGWBRTX64HY/