Re: pip and missing shared system system library

--===============3775733055208983309==
Content-Type: multipart/alternative;
	boundary="----=_Part_348583_1838807084.1596942911545"

------=_Part_348583_1838807084.1596942911545
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


       =20

       =20
            If you want to push a little further. Often when you build an e=
xtension which statically or dynamically link another library. You will nee=
d 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 supp=
osed to find out? Many library will expose a flag that tells you which comp=
iler version or range of version can be used. But no standard on this matte=
r...Don't get me wrong would be awesome if it worked. I just don't see a wa=
y to handle all these contraints ...Jonathan=C2=A0---- On ven., 07 ao=C3=BB=
t 2020 10:28:50 -0700  David Mathog<[email protected]> wrote ----> Unfortun=
ately, successfully building C libraries is way, way more > complicated tha=
n 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 f=
ar from universal.  Agreed that building a library is more complicated.  (B=
uilding a library, or anything for that matter, which depends on boost is e=
ven worse.)  Nevertheless, to do so the information provided by pkg-config =
will always be required.  It might not be sufficient, of course.  As for lo=
oking up this information, I am only aware of pkg-config and pkgconf, and o=
n many systems one is just a soft link to the other. That is also what is u=
sed on Windows within Mingw.  So it would not be unreasonable to specify th=
at this is the source of the information in all Posix environments.  > Ther=
e can be multiple versions of libpng on the same system, with different ABI=
s.  Requires-External supports version ranges and pkg-config will show the =
version which is installed.  If Requires-External is to ever have a real us=
age presumably it would have to be compatible with pkg-config in Posix envi=
ronments.  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 runn=
ing pip or these would not be found.  They would also have to specify "libn=
ame" or "libname2", as appropriate, in some cases.  > doesn't even know wha=
t compiler the package will want to use (which > also affects which librari=
es are available).  I had wondered about that.  In the spec it has an examp=
le:  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 t=
he case that started this thread a simple "The igraph library is required b=
ut 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 h=
ave currently.  > What pip *has* done in the last few years is made it poss=
ible 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 bu=
ilt 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 Py=
PI 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 w=
ay to distinguish between "this package has no external requirements" and "=
the external requirement specification is incomplete".  This information re=
ally 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 analogo=
us to  "johnnydep" which would traverse a proposed package install and veri=
fy that all the Requires-External entries are in fact satisfied, or minimal=
ly, just list them.  Pip should warn when no "Requires-External" entries ar=
e present, and "Requires-External none" would always suppress that warning.=
  Regards,  David Mathog -- Distutils-SIG mailing list -- distutils-sig@pyt=
hon.org To unsubscribe send an email to [email protected] http=
s://mail.python.org/mailman3/lists/distutils-sig.python.org/ Message archiv=
ed at https://mail.python.org/archives/list/[email protected]/messag=
e/BMLRH2JXM2B5EQAJ5NA44LGWBRTX64HY/=20
       =20
       =20

   =20
   =20


------=_Part_348583_1838807084.1596942911545
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>=
<meta content=3D"text/html;charset=3DUTF-8" http-equiv=3D"Content-Type"></h=
ead><body ><div style=3D'font-size:10pt;font-family:Verdana,Arial,Helvetica=
,sans-serif;color:#000000;'><div ><div>If you want to push a little further=
. Often when you build an extension which statically or dynamically link an=
other library. You will need to use the same compiler. Otherwise you might =
bump into ABI comptability issues.</div><div>So do you plan on "managing" w=
hich version of GCC or g++ people have and issue a warning if they don't ha=
ve the good one? How are you even supposed to find out? Many library will e=
xpose a flag that tells you which compiler version or range of version can =
be used. But no standard on this matter...</div><div><br></div><div>Don't g=
et me wrong would be awesome if it worked. I just don't see a way to handle=
 all these contraints ...</div><div><br></div><div>Jonathan&nbsp;</div><div=
><br></div><div></div></div><div><br><br></div><div class=3D"replyHeader">-=
--- On ven., 07 ao=C3=BBt 2020 10:28:50 -0700  David Mathog&lt;dmathog@gmai=
l.com&gt; wrote ----</div><div><br></div><blockquote style=3D"border-left: =
1px solid rgb(204, 204, 204); padding-left: 6px; margin-left: 5px;"><div>&g=
t; Unfortunately, successfully building C libraries is way, way more <br>&g=
t; complicated than that. There are nearly as many ways to detect and <br>&=
gt; configure C libraries as there are C libraries; tools like pkg-config <=
br>&gt; help a bit but they're far from universal. <br> <br>Agreed that bui=
lding a library is more complicated.  (Building a <br>library, or anything =
for that matter, which depends on boost is even <br>worse.)  Nevertheless, =
to do so the information provided by pkg-config <br>will always be required=
.  It might not be sufficient, of course.  As <br>for looking up this infor=
mation, I am only aware of pkg-config and <br>pkgconf, and on many systems =
one is just a soft link to the other. <br>That is also what is used on Wind=
ows within Mingw.  So it would not be <br>unreasonable to specify that this=
 is the source of the information in <br>all Posix environments. <br> <br>&=
gt; There can be multiple versions of libpng on the same system, with diffe=
rent ABIs. <br> <br>Requires-External supports version ranges and pkg-confi=
g will show the <br>version which is installed.  If Requires-External is to=
 ever have a <br>real usage presumably it would have to be compatible with =
pkg-config <br>in Posix environments.  That is, how would it ever work othe=
rwise? <br>Users who have placed pc files in odd locations would have to mo=
dify <br>PKG_CONFIG_PATH before running pip <br>or these would not be found=
.  They would also have to specify <br>"libname" or "libname2", as appropri=
ate, in some cases. <br> <br>&gt; doesn't even know what compiler the packa=
ge will want to use (which <br>&gt; also affects which libraries are availa=
ble). <br> <br>I had wondered about that.  In the spec it has an example: <=
br> <br>Requires-External C <br> <br>which seems to be a requirement for a =
C compiler, but if it does not <br>specify which one, then the test could p=
ass if it finds the Intel <br>compiler even though setup.py only knows how =
to build with gcc.  Or <br>vice versa. <br><br>&gt; day, the only thing pip=
 could do with this information is print a <br>&gt; slightly nicer error me=
ssage than you would get otherwise. <br> <br>In the case that started this =
thread a simple "The igraph library is <br>required but not installed on th=
is operating system" and then exit <br>would have saved a considerable amou=
nt of time.  So while it isn't <br>much, it is more than we have currently.=
 <br> <br>&gt; What pip *has* done in the last few years is made it possibl=
e to pull <br>&gt; in packages from PyPI when building packages from source=
, so you can <br>&gt; make your own pkg-config-handling library and put it =
on PyPI and <br>&gt; encourage everyone to use it instead of reinventing th=
e wheel. Or use <br>&gt; more powerful build systems that have already solv=
ed these problems, <br>&gt; e.g. scikit-build lets you use CMake to build p=
ython packages. <br> <br>I think that is what happened this time, but there=
 was no test to see <br>if the package it built could be installed where it=
 wanted to put it, <br>so it failed.  At least I think that is what happene=
d.  In any case, <br>it did pull igraph down from PyPI but the installation=
 failed. <br> <br>One other point about "Requires-External" - as described,=
 it lacks a <br>special case "none".   (None really means "just the python =
version <br>which is running pip".) That is, there is currently no way to <=
br>distinguish between "this package has no external requirements" and <br>=
"the external requirement specification is incomplete".  This <br>informati=
on really should be mandatory, even if it is just to tell a <br>person what=
 must be installed in the OS before running pip.   One can <br>imagine a ut=
ility analogous to  "johnnydep" which would traverse a <br>proposed package=
 install and verify that all the Requires-External <br>entries are in fact =
satisfied, or minimally, just list them.  Pip <br>should warn when no "Requ=
ires-External" entries are present, and <br>"Requires-External none" would =
always suppress that warning. <br> <br>Regards, <br> <br>David Mathog <br>-=
- <br>Distutils-SIG mailing list -- <a href=3D"mailto:distutils-sig@python.=
org" target=3D"_blank">[email protected]</a> <br>To unsubscribe send=
 an email to <a href=3D"mailto:[email protected]" target=3D"_b=
lank">[email protected]</a> <br><a href=3D"https://mail.python=
.org/mailman3/lists/distutils-sig.python.org/" target=3D"_blank">https://ma=
il.python.org/mailman3/lists/distutils-sig.python.org/</a> <br>Message arch=
ived at <a href=3D"https://mail.python.org/archives/list/distutils-sig@pyth=
on.org/message/BMLRH2JXM2B5EQAJ5NA44LGWBRTX64HY/" target=3D"_blank">https:/=
/mail.python.org/archives/list/[email protected]/message/BMLRH2JXM2B=
5EQAJ5NA44LGWBRTX64HY/</a> <br></div></blockquote></div><br></body></html>
------=_Part_348583_1838807084.1596942911545--

--===============3775733055208983309==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/archives/list/[email protected]/message/JSTXSJVVNNPT6LNTQLDWZZTKH6YRM6VF/

--===============3775733055208983309==--