> 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-le...@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/