
Hello, After updating to v4.8.0 this morning, entire workflows started to fail. After some digging around I could narrow it down to a regression introduced between v4.7.1 and v4.8.0. This example code import lxml.etree xml = lxml.etree.XML(""" <a> <b id="b-1"> <c id="b-1-c">baz</c> </b> <b id="b-2"> <c id="b-2-c">baz</c> </b> <b id="b-3"> <c id="b-3-c">baz</c> </b> </a> """) print(len(xml)) for elm in xml: print(elm, lxml.etree.tostring(elm)) On v4.7.1 I get the expected result 3 <Element b at 0x10ad5d080> b'<b id="b-1">\n <c id="b-1-c">baz</c>\n </b>\n ' <Element b at 0x10ad5d100> b'<b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n ' <Element b at 0x10ad5d140> b'<b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n’ On v4.8.0 the following: 3 <Element b at 0x1061cc100> b'<b id="b-1">\n <c id="b-1-c">baz</c>\n </b>\n <b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n <b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n</a>\n ' <Element b at 0x1061cc180> b'<b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n <b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n</a>\n ' <Element b at 0x1061cc1c0> b'<b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n</a>\n’ Now scale that for nodes with hundreds of children and you’ll get an idea of what happened this morning 😉 Cheers, Jens -- Jens Tröger https://savage.light-speed.de/

On Mon, Feb 21, 2022 at 3:00 AM Jens Tröger <jens.troeger@light-speed.de> wrote:
After updating to v4.8.0 this morning, entire workflows started to fail. After some digging around I could narrow it down to a regression introduced between v4.7.1 and v4.8.0.
Interesting. I was not able to reproduce that behavior, which is indeed unsettling. I ran your code (with the addition of a line to print out the version of lxml) under Python 3.10.1 with 4.8.0 and I got the expected (correct) output. This is on macOS 12.2.1 (M1). Another interesting data point is that although https://pypi.org/project/lxml/ claims that there are builds of 4.8.0 for Python 3.10, pip on this machine concluded that it needed to build lxml from code. Perhaps an M1 thing? I will see what happens on Linux and Windows. -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

On Mon, Feb 21, 2022 at 11:14 AM Bob Kline <bkline@rksystems.com> wrote:
... I will see what happens on Linux and Windows.
I see the same (correct) behavior with Linux (Python 3.8.10) and Windows 10 (Python 3.10.1). Did you create a custom build of the package? Also, I realize that subtle differences in whitespace are not a likely culprit, given that you are seeing the same incorrect output from your repro code as from your production code, but I wonder if it might be better to provide the repro code in some other way than by pasting it into the body of an email message, so that we are confident that I am running, byte-for-byte, *exactly* the same code as you are running. Email message bodies, as the messages pass from one system or email client to the next, are subject to subtle modifications to which binary attachments should be immune. I recognize that this is a stab in the dark, but nothing else jumps out as a culprit. -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

Yes, when I installed lxml it built locally on my Intel Mac 10.14.6 with Python 3.9.10, and in another email I actually wanted to ask for a pre-compiled whl: Collecting lxml Using cached lxml-4.8.0.tar.gz (3.2 MB) Using legacy 'setup.py install' for lxml, since package 'wheel' is not installed. Installing collected packages: lxml Running setup.py install for lxml ... done Successfully installed lxml-4.8.0 Jens
-- Jens Tröger https://savage.light-speed.de/

On 21 Feb 2022, at 20:37, Jens Tröger wrote:
FWIW I can confirm that this happens if lxml is built on the machine but not with the wheel This is locally build lxml Python : sys.version_info(major=3, minor=9, micro=10, releaselevel='final', serial=0) lxml.etree : (4, 8, 0, 0) libxml used : (2, 9, 12) libxml compiled : (2, 9, 12) libxslt used : (1, 1, 34) libxslt compiled : (1, 1, 34) 3 <Element b at 0x103815a00> b'<b id="b-1">\n <c id="b-1-c">baz</c>\n </b>\n <b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n <b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n</a>\n ' <Element b at 0x103815a40> b'<b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n <b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n</a>\n ' <Element b at 0x103815a80> b'<b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n</a>\n' And this with the wheel Python : sys.version_info(major=3, minor=9, micro=10, releaselevel='final', serial=0) lxml.etree : (4, 8, 0, 0) libxml used : (2, 9, 12) libxml compiled : (2, 9, 12) libxslt used : (1, 1, 34) libxslt compiled : (1, 1, 34) 3 <Element b at 0x101b1b9c0> b'<b id="b-1">\n <c id="b-1-c">baz</c>\n </b>\n ' <Element b at 0x101b1ba00> b'<b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n ' <Element b at 0x101b1ba40> b'<b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n' All libraries have the same version so it must be something else. I use MacPorts to keep libraries up to date. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

Well… I’m glad you can reproduce this 😉 Same here, MacPorts for a package manager. Anything I can try/test/provide to help fix this? Cheers, Jens
-- Jens Tröger https://savage.light-speed.de/

On 22 Feb 2022, at 10:00, Jens Tröger wrote:
Well… I’m glad you can reproduce this 😉 Same here, MacPorts for a package manager.
Anything I can try/test/provide to help fix this?
It's well beyond my skillset but if Stefan has an idea then I'm sure he'll let us know. At least now it's knowably reproducible then that should make tracking the problem down easier. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On Tue, Feb 22, 2022 at 3:48 AM Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
My system (on which the locally-built lxml 4.8.0 behaves correctly for the repro script) uses homebrew instead of MacPorts, which seems like a possibly useful clue. -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

Charlie Clark schrieb am 22.02.22 um 09:48:
Sadly, libxml2 2.9.12 is not libxml2 2.9.12 here. On your machine, you probably have the latest release version installed. The lxml wheels are built with a newer git version that has a fix for this issue. Or a work-around, if you want. If you set STATIC_BUILD=true, and LIBXML_VERSION=2.9.12, lxml will use the git version instead of the release version. It would probably be worth adding a runtime detection for this issue, so that lxml can fail to import if it finds an incompatible libxml2 version. The broken behaviour seems heavy enough to fail hard instead of issuing just a warning (which the build currently does, but you normally won't see that in pip installations). Stefan

On 22 Feb 2022, at 17:26, Stefan Behnel wrote:
If you set STATIC_BUILD=true, and LIBXML_VERSION=2.9.12, lxml will use the git version instead of the release version.
I just tried this but got the same result. Presumably, I did something wrong but ENVVARs are not my strength anyway. However, it sounds very much like a know issue that will hopefully disappear once 2.9.13 is released. MacPorts is normally pretty up to date, but I see that this hasn't been updated for nine months but 2.9.13 was only released on the 19th of February. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 22 Feb 2022, at 18:02, Stefan Behnel wrote:
Yes, 2.9.13 was freshly released. That may explain why it works for Bob. A static build would pick up the latest version.
There's not a ticket for it on MacPorts or a PR. I'll try and submit one tomorrow, if I can remember how to! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Waldlehne 23 Düsseldorf D- 40489 Mobile: +49-178-782-6226

On Tue, Feb 22, 2022 at 12:14 PM Stefan Behnel <stefan_ml@behnel.de> wrote:
... Yes, 2.9.13 was freshly released. That may explain why it works for Bob.
Or possibly the other way around. My understanding of the difference between homebrew (which I'm using) and MacPorts (which the O.P. uses) is that homebrew relies more on resources already supplied by the OS, whereas MacPorts builds more of what it needs from scratch (sort of the same general relationship—in a vague way—as between Docker and VMWare). So on my machine libxml is at version 2.9.4, and therefore I assume I'm working with a version released *before* the bug was introduced, not a version released *after* it was fixed. -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

On 22 Feb 2022, at 20:18, Bob Kline wrote:
Sounds like it. MacPorts are just very similar to BSD ports and are supposed to be separate from the OS, which gets updated less often. Can't wait for Apple to release fixes for things like SSL… I just wish Apple would get fully behind MacPorts and spend less time fiddling with all the posix stuff! Well, one is allowed to wish! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 22 Feb 2022, at 17:51, Charlie Clark wrote:
However, it sounds very much like a know issue that will hopefully disappear once 2.9.13 is released. MacPorts is normally pretty up to date, but I see that this hasn't been updated for nine months but 2.9.13 was only released on the 19th of February.
I've started preparing for a PR for this but I'm stumped because 2.9.13 doesn't appear to be on the FTP-server! Stefan, am I looking in the right place? Or has something gone wrong with their release management? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 23 Feb 2022, at 8:59, Charlie Clark wrote:
I've started preparing for a PR for this but I'm stumped because 2.9.13 doesn't appear to be on the FTP-server! Stefan, am I looking in the right place? Or has something gone wrong with their release management?
Ah, okay found it in the release e-mail: """ Note that starting with this release, libxml2 tarballs are published on download.gnome.org instead of ftp.xmlsoft.org. """ Grumble, grumble about note missing on the homepage and FTP server. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 23 Feb 2022, at 9:06, Charlie Clark wrote:
Grumble, grumble about note missing on the homepage and FTP server.
Updated my local ports repo and things are looking better! There's a note about keeping the Python bindings in sync so I'll check that and submit a PR. Python : sys.version_info(major=3, minor=9, micro=10, releaselevel='final', serial=0) lxml.etree : (4, 8, 0, 0) libxml used : (2, 9, 13) libxml compiled : (2, 9, 13) libxslt used : (1, 1, 34) libxslt compiled : (1, 1, 34) 3 <Element b at 0x10855dc40> b'<b id="b-1">\n <c id="b-1-c">baz</c>\n </b>\n ' <Element b at 0x10855dcc0> b'<b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n ' <Element b at 0x10855dd00> b'<b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n' Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 23 Feb 2022, at 10:17, Charlie Clark wrote:
Updated my local ports repo and things are looking better! There's a note about keeping the Python bindings in sync so I'll check that and submit a PR.
See https://github.com/macports/macports-ports/pull/14096 Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

Bob Kline schrieb am 21.02.22 um 17:14:
The macOS wheels are not currently compatible with M1, so you end up with a local build instead. Help with building more universal macOS wheels would be appreciated. I guess a switch to cibuildwheels would help, but I doubt that that's done lightly. Stefan

On Tue, Feb 22, 2022 at 11:20 AM Stefan Behnel <stefan_ml@behnel.de> wrote:
... Help with building more universal macOS wheels would be appreciated.
What would that involve? -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

Bob Kline schrieb am 22.02.22 um 17:29:
As I wrote, cibuildwheels probably has a way to do it from Github Actions, but changing build systems (or replacing the build configuration) isn't exactly something I'd like to put work into right now. I'm not saying that it would be difficult, just that it needs doing and testing, and probably a couple of iterations until everything runs smoothly again. Stefan

On 22 Feb 2022, at 17:13, Stefan Behnel wrote:
The macOS wheels are not currently compatible with M1, so you end up with a local build instead.
FWIW both me and Jens have Intel Macs and Bob has an M1 so that doesn't explain the actual problem. But we did test with different Python versions. Easy enough to check against those, though. Jens, did you see the same behaviour with different versions of Python? Stefan, do you suspect anything in particular that could be responsible for the repetition? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

Thank you all for the conversation. My local MacPorts libxml2 is whatever is their latest: > port info libxml2 libxml2 @2.9.12_1 (textproc) > port installed | grep xml ... 195: libxml2 @2.9.12_1 (active)
Jens, did you see the same behaviour with different versions of Python?
I just installed lxml for 3.9.10 and 3.10.2 and 3.11.0a4, and it showed the same issue with all of these versions. In all cases `pip` built the package because no whl was available. Cheers Jens -- Jens Tröger https://savage.light-speed.de/

On Mon, Feb 21, 2022 at 3:00 AM Jens Tröger <jens.troeger@light-speed.de> wrote:
After updating to v4.8.0 this morning, entire workflows started to fail. After some digging around I could narrow it down to a regression introduced between v4.7.1 and v4.8.0.
Interesting. I was not able to reproduce that behavior, which is indeed unsettling. I ran your code (with the addition of a line to print out the version of lxml) under Python 3.10.1 with 4.8.0 and I got the expected (correct) output. This is on macOS 12.2.1 (M1). Another interesting data point is that although https://pypi.org/project/lxml/ claims that there are builds of 4.8.0 for Python 3.10, pip on this machine concluded that it needed to build lxml from code. Perhaps an M1 thing? I will see what happens on Linux and Windows. -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

On Mon, Feb 21, 2022 at 11:14 AM Bob Kline <bkline@rksystems.com> wrote:
... I will see what happens on Linux and Windows.
I see the same (correct) behavior with Linux (Python 3.8.10) and Windows 10 (Python 3.10.1). Did you create a custom build of the package? Also, I realize that subtle differences in whitespace are not a likely culprit, given that you are seeing the same incorrect output from your repro code as from your production code, but I wonder if it might be better to provide the repro code in some other way than by pasting it into the body of an email message, so that we are confident that I am running, byte-for-byte, *exactly* the same code as you are running. Email message bodies, as the messages pass from one system or email client to the next, are subject to subtle modifications to which binary attachments should be immune. I recognize that this is a stab in the dark, but nothing else jumps out as a culprit. -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

Yes, when I installed lxml it built locally on my Intel Mac 10.14.6 with Python 3.9.10, and in another email I actually wanted to ask for a pre-compiled whl: Collecting lxml Using cached lxml-4.8.0.tar.gz (3.2 MB) Using legacy 'setup.py install' for lxml, since package 'wheel' is not installed. Installing collected packages: lxml Running setup.py install for lxml ... done Successfully installed lxml-4.8.0 Jens
-- Jens Tröger https://savage.light-speed.de/

On 21 Feb 2022, at 20:37, Jens Tröger wrote:
FWIW I can confirm that this happens if lxml is built on the machine but not with the wheel This is locally build lxml Python : sys.version_info(major=3, minor=9, micro=10, releaselevel='final', serial=0) lxml.etree : (4, 8, 0, 0) libxml used : (2, 9, 12) libxml compiled : (2, 9, 12) libxslt used : (1, 1, 34) libxslt compiled : (1, 1, 34) 3 <Element b at 0x103815a00> b'<b id="b-1">\n <c id="b-1-c">baz</c>\n </b>\n <b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n <b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n</a>\n ' <Element b at 0x103815a40> b'<b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n <b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n</a>\n ' <Element b at 0x103815a80> b'<b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n</a>\n' And this with the wheel Python : sys.version_info(major=3, minor=9, micro=10, releaselevel='final', serial=0) lxml.etree : (4, 8, 0, 0) libxml used : (2, 9, 12) libxml compiled : (2, 9, 12) libxslt used : (1, 1, 34) libxslt compiled : (1, 1, 34) 3 <Element b at 0x101b1b9c0> b'<b id="b-1">\n <c id="b-1-c">baz</c>\n </b>\n ' <Element b at 0x101b1ba00> b'<b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n ' <Element b at 0x101b1ba40> b'<b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n' All libraries have the same version so it must be something else. I use MacPorts to keep libraries up to date. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

Well… I’m glad you can reproduce this 😉 Same here, MacPorts for a package manager. Anything I can try/test/provide to help fix this? Cheers, Jens
-- Jens Tröger https://savage.light-speed.de/

On 22 Feb 2022, at 10:00, Jens Tröger wrote:
Well… I’m glad you can reproduce this 😉 Same here, MacPorts for a package manager.
Anything I can try/test/provide to help fix this?
It's well beyond my skillset but if Stefan has an idea then I'm sure he'll let us know. At least now it's knowably reproducible then that should make tracking the problem down easier. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On Tue, Feb 22, 2022 at 3:48 AM Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
My system (on which the locally-built lxml 4.8.0 behaves correctly for the repro script) uses homebrew instead of MacPorts, which seems like a possibly useful clue. -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

Charlie Clark schrieb am 22.02.22 um 09:48:
Sadly, libxml2 2.9.12 is not libxml2 2.9.12 here. On your machine, you probably have the latest release version installed. The lxml wheels are built with a newer git version that has a fix for this issue. Or a work-around, if you want. If you set STATIC_BUILD=true, and LIBXML_VERSION=2.9.12, lxml will use the git version instead of the release version. It would probably be worth adding a runtime detection for this issue, so that lxml can fail to import if it finds an incompatible libxml2 version. The broken behaviour seems heavy enough to fail hard instead of issuing just a warning (which the build currently does, but you normally won't see that in pip installations). Stefan

On 22 Feb 2022, at 17:26, Stefan Behnel wrote:
If you set STATIC_BUILD=true, and LIBXML_VERSION=2.9.12, lxml will use the git version instead of the release version.
I just tried this but got the same result. Presumably, I did something wrong but ENVVARs are not my strength anyway. However, it sounds very much like a know issue that will hopefully disappear once 2.9.13 is released. MacPorts is normally pretty up to date, but I see that this hasn't been updated for nine months but 2.9.13 was only released on the 19th of February. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 22 Feb 2022, at 18:02, Stefan Behnel wrote:
Yes, 2.9.13 was freshly released. That may explain why it works for Bob. A static build would pick up the latest version.
There's not a ticket for it on MacPorts or a PR. I'll try and submit one tomorrow, if I can remember how to! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Waldlehne 23 Düsseldorf D- 40489 Mobile: +49-178-782-6226

On Tue, Feb 22, 2022 at 12:14 PM Stefan Behnel <stefan_ml@behnel.de> wrote:
... Yes, 2.9.13 was freshly released. That may explain why it works for Bob.
Or possibly the other way around. My understanding of the difference between homebrew (which I'm using) and MacPorts (which the O.P. uses) is that homebrew relies more on resources already supplied by the OS, whereas MacPorts builds more of what it needs from scratch (sort of the same general relationship—in a vague way—as between Docker and VMWare). So on my machine libxml is at version 2.9.4, and therefore I assume I'm working with a version released *before* the bug was introduced, not a version released *after* it was fixed. -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

On 22 Feb 2022, at 20:18, Bob Kline wrote:
Sounds like it. MacPorts are just very similar to BSD ports and are supposed to be separate from the OS, which gets updated less often. Can't wait for Apple to release fixes for things like SSL… I just wish Apple would get fully behind MacPorts and spend less time fiddling with all the posix stuff! Well, one is allowed to wish! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 22 Feb 2022, at 17:51, Charlie Clark wrote:
However, it sounds very much like a know issue that will hopefully disappear once 2.9.13 is released. MacPorts is normally pretty up to date, but I see that this hasn't been updated for nine months but 2.9.13 was only released on the 19th of February.
I've started preparing for a PR for this but I'm stumped because 2.9.13 doesn't appear to be on the FTP-server! Stefan, am I looking in the right place? Or has something gone wrong with their release management? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 23 Feb 2022, at 8:59, Charlie Clark wrote:
I've started preparing for a PR for this but I'm stumped because 2.9.13 doesn't appear to be on the FTP-server! Stefan, am I looking in the right place? Or has something gone wrong with their release management?
Ah, okay found it in the release e-mail: """ Note that starting with this release, libxml2 tarballs are published on download.gnome.org instead of ftp.xmlsoft.org. """ Grumble, grumble about note missing on the homepage and FTP server. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 23 Feb 2022, at 9:06, Charlie Clark wrote:
Grumble, grumble about note missing on the homepage and FTP server.
Updated my local ports repo and things are looking better! There's a note about keeping the Python bindings in sync so I'll check that and submit a PR. Python : sys.version_info(major=3, minor=9, micro=10, releaselevel='final', serial=0) lxml.etree : (4, 8, 0, 0) libxml used : (2, 9, 13) libxml compiled : (2, 9, 13) libxslt used : (1, 1, 34) libxslt compiled : (1, 1, 34) 3 <Element b at 0x10855dc40> b'<b id="b-1">\n <c id="b-1-c">baz</c>\n </b>\n ' <Element b at 0x10855dcc0> b'<b id="b-2">\n <c id="b-2-c">baz</c>\n </b>\n ' <Element b at 0x10855dd00> b'<b id="b-3">\n <c id="b-3-c">baz</c>\n </b>\n' Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

On 23 Feb 2022, at 10:17, Charlie Clark wrote:
Updated my local ports repo and things are looking better! There's a note about keeping the Python bindings in sync so I'll check that and submit a PR.
See https://github.com/macports/macports-ports/pull/14096 Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

Bob Kline schrieb am 21.02.22 um 17:14:
The macOS wheels are not currently compatible with M1, so you end up with a local build instead. Help with building more universal macOS wheels would be appreciated. I guess a switch to cibuildwheels would help, but I doubt that that's done lightly. Stefan

On Tue, Feb 22, 2022 at 11:20 AM Stefan Behnel <stefan_ml@behnel.de> wrote:
... Help with building more universal macOS wheels would be appreciated.
What would that involve? -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

Bob Kline schrieb am 22.02.22 um 17:29:
As I wrote, cibuildwheels probably has a way to do it from Github Actions, but changing build systems (or replacing the build configuration) isn't exactly something I'd like to put work into right now. I'm not saying that it would be difficult, just that it needs doing and testing, and probably a couple of iterations until everything runs smoothly again. Stefan

On 22 Feb 2022, at 17:13, Stefan Behnel wrote:
The macOS wheels are not currently compatible with M1, so you end up with a local build instead.
FWIW both me and Jens have Intel Macs and Bob has an M1 so that doesn't explain the actual problem. But we did test with different Python versions. Easy enough to check against those, though. Jens, did you see the same behaviour with different versions of Python? Stefan, do you suspect anything in particular that could be responsible for the repetition? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Sengelsweg 34 Düsseldorf D- 40489 Tel: +49-203-3925-0390 Mobile: +49-178-782-6226

Thank you all for the conversation. My local MacPorts libxml2 is whatever is their latest: > port info libxml2 libxml2 @2.9.12_1 (textproc) > port installed | grep xml ... 195: libxml2 @2.9.12_1 (active)
Jens, did you see the same behaviour with different versions of Python?
I just installed lxml for 3.9.10 and 3.10.2 and 3.11.0a4, and it showed the same issue with all of these versions. In all cases `pip` built the package because no whl was available. Cheers Jens -- Jens Tröger https://savage.light-speed.de/
participants (4)
-
Bob Kline
-
Charlie Clark
-
Jens Tröger
-
Stefan Behnel