On Thu, Aug 6, 2020 at 3:06 PM David Mathog <dmat...@gmail.com> wrote: > > On Thu, Aug 6, 2020 at 11:54 AM Nathaniel Smith <n...@pobox.com> wrote: > > > If the code that failed to give a good error message is in > > louvain-igraph, then you should probably talk to them about that :-). > > There's no way for the core packaging libraries to guess what this > > kind of arbitrary package-specific code is going to do. > > That was the point I was trying to make, albeit not very well I guess. > Because Requires-External was not supplied, and pip would not have > done anything with it even if it had been, the package had to roll its > own. The documentation for Requires-External says what it requires, > but it does not indicate that anything else happens besides (I assume) > the installation halting if the condition is not met. That is, if > there is: > > Requires-External: libpng > > and pip acts on it that meant it found libpng.so, but there does not > seem to be any requirement that it communicate any further information > about libpng to setup.py in any standard way. Which is why the > setup.py for louvain rolled its own. For posixy OS's it would be > sufficient to know that if the "Requires-External" passed that > "pkg-config --cflags libpng" and the like will work. But again, that > pushes the work into setup.py where it will not be standardized nor > platform agnostic. So for better portability passing one of these > tests should also set some standard variables like: > > RE_libpng_cflags="-lpng16 -lz" > RE_libpng_includedir="/usr/include" > RE_libpng_libdir="/usr/lib64" > (and so forth). > > which are then seen in setup.py. Yes, these are just the various > values already in the libpng.pc file, no reason to reinvent that > wheel. The result should be simpler setup.py's which are portable > without requiring all the conditional "if it is this OS then look > here" that they must currently contain.
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. There can be multiple versions of libpng on the same system, with different ABIs. pip doesn't even know what compiler the package will want to use (which also affects which libraries are available). And at the end of the day, the only thing pip could do with this information is print a slightly nicer error message than you would get otherwise. 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. -n -- Nathaniel J. Smith -- https://vorpus.org -- 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/B5D2GDJZPZ73Q4JKJBVYX7U5HUCY26TA/
