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
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 : sy
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 releas
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 o
On 22 Feb 2022, at 20:18, Bob Kline wrote:
> 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
On Tue, Feb 22, 2022 at 12:14 PM Stefan Behnel 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
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 schrieb am 22.02.22 um 17:51:
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
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
Bob Kline schrieb am 22.02.22 um 17:29:
On Tue, Feb 22, 2022 at 11:20 AM Stefan Behnel wrote:
...
Help with building more universal macOS wheels would be appreciated.
What would that involve?
Finding a good way to do it. :)
As I wrote, cibuildwheels probably has a way to do it from Github Ac
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.
Charlie Clark schrieb am 22.02.22 um 09:48:
On 21 Feb 2022, at 20:37, Jens Tröger wrote:
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.g
On Tue, Feb 22, 2022 at 11:20 AM Stefan Behnel wrote:
> ...
> Help with building more universal macOS wheels would be appreciated.
What would that involve?
--
Bob Kline
https://www.rksystems.com
mailto:bkl...@rksystems.com
___
lxml - The Python XML To
Bob Kline schrieb am 21.02.22 um 17:14:
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
On Tue, Feb 22, 2022 at 3:48 AM Charlie Clark
wrote:
> FWIW I can confirm that this happens if lxml is built on the machine but not
> with the wheel
> ...
> All libraries have the same version so it must be something else. I use
> MacPorts to keep libraries up to date.
My system (on which the l
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 kno
On 21 Feb 2022, at 20:37, Jens Tröger wrote:
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'
On Mon, Feb 21, 2022 at 11:14 AM Bob Kline 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
On Mon, Feb 21, 2022 at 3:00 AM Jens Tröger 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
19 matches
Mail list logo
