Planning the next release

[mxamin]

Let's discuss the next release :)

@jonathangreen
@jimjag

[mxamin]

So far these are the two important issues that need to be handled:
#314
#316

[jonathangreen]

Agreed @mxamin, I think those are the most important as well. I think distributing wheels for Linux #316 will make #314 less important because fewer people will be compiling themselves, but it would still be nice to handle #314 if we can.

[mxamin]

Agreed @mxamin, I think those are the most important as well. I think distributing wheels for Linux #316 will make #314 less important because fewer people will be compiling themselves, but it would still be nice to handle #314 if we can.

@jonathangreen I agree, I uploaded the linux wheels in the release note. Can you check that for the reported cases using the wheels would actually solve the problem?

[jonathangreen]

It doesn't have to be for next release, the issue has been open for a while, but I think we should look into #239 in the next couple releases.

That issue was written by the maintainer of lxml so the suggestion of how we should be calling the lxml api should be taken seriously.

[jonathangreen]

@jonathangreen I agree, I uploaded the linux wheels in the release note. Can you check that for the reported cases using the wheels would actually solve the problem?

@mxamin I made a small workflow here to test our built wheels for linux, osx and windows against the lxml wheels by running our tests. It shows that the wheels work for lxml >= 5.0. From what I can see in the bug reports that included their lxml version they it seems installing wheels would fix issues for all those reports.

[mxamin]

Great, then I'll upload the rest of wheels.

Update: It's done

[ryanhiebert]

If you don’t mind my asking, does this mean that if I install binary versions for the latest version of lxml and this package that I should be good?

[jonathangreen]

@ryanhiebert yes that is correct! That is what I expect based on my testing anyway.

[mxamin]

FYI, I'm gonna have limited/no access up until May 11th :)

[antoniomika]

It seems there are inconsistencies now for people that solved an issue previously between lxml and xmlsec by installing lxml without binaries and expecting to use system installed libraries. There are clearly binaries for xmlsec now available on PyPi, which has broken installs. The README mentions needing to install system libraries for Linux, but this is not the case anymore (although, other issues on GitHub mention there are no binary wheels available for xmlsec).

What is the desired case now? Will xmlsec always ship binaries that are compatible with lxml? If not, is the expectation to use --no-binary for both lxml and xmlsec?

Happy for either, I'd just like to make sure this is documented for others!

[jimjag]

This works for me. If desired, I can submit this one to PyPI to help w/ the bus factor