Push 3.10 wheels to Pypi

[TheQuinbox]

Operating system: Windows 10 21H1 (x64) build 19043.1586

wxPython version & source:
Pypi (attempting) Python version & source: Stock Description of the problem: WXPython 4.11 doesn't install on Windows in Python 3.10. This seems to have been fixed in #2017, but the wheels haven't been pushed yet. It would be great if this could be done.

[hoba87]

There is a (official) wxpython310 package on pypi.org. I don't know if the 310 postfix is intended...

[TheQuinbox]

@hoba87, I'm not sure, but I can tell you first hand that typing

pip install wxpython

on python 3.10.2 still doesn't work, so I assume it wasn't included.

[swt2c]

There is a (official) wxpython310 package on pypi.org. I don't know if the 310 postfix is intended...

That's not an official wxPython package.

[hoba87]

There is a (official) wxpython310 package on pypi.org. I don't know if the 310 postfix is intended...

That's not an official wxPython package.

Oh sorry, it just looked like, because it seems to be a clone of the official package.

[hoba87]

@TheQuinbox as said above, nothing official, but if you want to try: https://pypi.org/project/wxPython310/

[swt2c]

I would recommend the snapshot builds instead: https://wxpython.org/Phoenix/snapshot-builds/

[TheQuinbox]

@swt2c, this installed on my python just fine, thank you :).

Do you think we should keep this issue open, just until the wheels get pushed? While this does work, having to download a wheel and install it is more steps for people, especially if you're running out of a git repository.

[newville]

@swt2c @hoba87 Please keep this issue open until actually resolved.

For those of us supporting pip-installable downstream libraries or bundling applications, using some non-standard package named something like "wxpython310" is a real pain. And the advice of "oh just use the snapshot builds" is fine for testing, but not a realistic scenario for packages or deployment tools.

Not having an easily installable wxPython package for Python 3.10 (which was first released in October 2021, so more than 16 months ago) is getting to be a problem for some of us. Thanks.

[oleksis]

Can follow the steps for compile wxPython in Python 3.10 or download the wheel

[newville]

@oleksis thanks. For me (and I believe the original issue here) is not about the ability for someone to download and install from some URL (either your wheel or the snapshot builds). Instead, the issue is that the package is not available on PyPI. That makes it very difficult to have wxpython as a dependency -- pip install wx_using_package will not resolve the dependency.

The result is that those of us writing downstream libraries or applications must use custom install scripts or other packaging systems (say, conda) instead of pip.

Is there something we can do to help get those posted? Wheels for Windows and macOS and only for wxPython 4.1.1 for Python 3.10 would be very helpful.

[ChrisBarker-NOAA]

note that I don't think there hasn't been a release on gitHub since March 2018 either -- which is really too bad, as I'd like to build conda packages from something "official".

There is a PyPi source release of 4.1.1 from Nov 2020 -- but that's getting pretty old.

[LexiconCode]

snapshot builds

I do not see any x86 builds for python 3.10.x

[ajkaijanaho]

Also, Python 3.9 is soon going to stop releasing binary updates, making it unsuitable for most deployments going forward. My team would like to be able to move our offering to Python 3.10, but the lack of an official wxPython release that supports 3.10 on Windows (and is available as a wheel in PyPI) is a major downside; we may have to consider rewriting the GUI using other libraries.

[ChrisBarker-NOAA]

@ajkaijanaho:

Really? py3.11 is only just in its first test release (or about to be. I think you're safe with 3.9 for some time.

End of support for 3.9 is 2025:

https://www.python.org/downloads/

If you want/need features from 3.10, that's one thing, but maintenance is not an issue for a while.

I think the bigger issue here is not 3.10 wheels, but overall releases -- unfortunately, desktop development doesn't get a whole lot of attention these days, so it's hard to keep up :-(

[ajkaijanaho]

@ajkaijanaho:

Really? py3.11 is only just in its first test release (or about to be. I think you're safe with 3.9 for some time.

End of support for 3.9 is 2025:

https://www.python.org/downloads/

The last binary release is scheduled for this coming Monday. Later support is source only, and deployment on Windows becomes more complicated. See https://peps.python.org/pep-0596/

I think the bigger issue here is not 3.10 wheels, but overall releases -- unfortunately, desktop development doesn't get a whole lot of attention these days, so it's hard to keep up :-(

Yes, the lack of releases is a concern. The lack of wheels is a more immediate issue for us.

[ChrisBarker-NOAA]

Interesting -- I wonder why they will only do source-opnly for security releases -- what with modern CI systems, there's not a whole lot of overhead to a binary release.

But anyway, no new binary releases doesn't mean you have to stop using it -- 3.9 will be viable for a long time yet.

However, I'm saying not to panic -- but the fact is that none of us want t rely on something that isn't being maintained. If this isn't resolved soon, I suppose a few of us that need this to move forward could make a only-for-releases fork of the project.

-CHB

[infinity77]

On Thu, 12 May 2022 at 18.23, Chris Barker @.***> wrote:

Interesting -- I wonder why they will only do source-opnly for security releases -- what with modern CI systems, there's not a whole lot of overhead to a binary release.

But anyway, no new binary releases doesn't mean you have to stop using it -- 3.9 will be viable for a long time yet.

However, I'm saying not to panic -- but the fact is that none of us want t rely on something that isn't being maintained. If this isn't resolved soon, I suppose a few of us that need this to move forward could make a only-for-releases fork of the project.

It would also be nice to know if Robin is all right, we haven’t heard from him for a very long time. I hope he is, and maybe he’s just very busy with other things.

Hopefully he hasn’t lost interest in wxPython.

Andrea.

-CHB

— Reply to this email directly, view it on GitHub https://github.com/wxWidgets/Phoenix/issues/2128#issuecomment-1125190579, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACESNIOUKH46WCLV4XXFOZLVJUV63ANCNFSM5QZEIR2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ajkaijanaho]

@ChrisBarker-NOAA

Interesting -- I wonder why they will only do source-opnly for security releases -- what with modern CI systems, there's not a whole lot of overhead to a binary release.

But anyway, no new binary releases doesn't mean you have to stop using it -- 3.9 will be viable for a long time yet.

Unfortunately, our clients quite sensibly require us to have a plan in place for deploying security updates in dependencies. Today, the plan for updating Python involves taking the binary Python installer and rebuilding our software with the new Python. After next week, that is no longer viable for Python 3.9. My preferred plan is to upgrade to Python 3.10, but wxPython is making that difficult. If we stay with Python 3.9, we need to create the capability to build Python from source (something we can do but I would rather not).

However, I'm saying not to panic -- but the fact is that none of us want t rely on something that isn't being maintained. If this isn't resolved soon, I suppose a few of us that need this to move forward could make a only-for-releases fork of the project.

I think a better plan would be to foster a true developer community around wxPython, with no single-person bottlenecks in any parts of the process. Unfortunately, that seems difficult at this time.

@infinity77

It would also be nice to know if Robin is all right, we haven’t heard from him for a very long time. I hope he is, and maybe he’s just very busy with other things. Hopefully he hasn’t lost interest in wxPython. Andrea.

I believe he just pushed some changes to master a couple of days ago.

[infinity77]

On Fri, 13 May 2022 at 08.09, Antti-Juhani Kaijanaho < @.***> wrote:

@ChrisBarker-NOAA https://github.com/ChrisBarker-NOAA

Interesting -- I wonder why they will only do source-opnly for security releases -- what with modern CI systems, there's not a whole lot of overhead to a binary release.

But anyway, no new binary releases doesn't mean you have to stop using it -- 3.9 will be viable for a long time yet.

Unfortunately, our clients quite sensibly require us to have a plan in place for deploying security updates in dependencies. Today, the plan for updating Python involves taking the binary Python installer and rebuilding our software with the new Python. After next week, that is no longer viable for Python 3.9. My preferred plan is to upgrade to Python 3.10, but wxPython is making that difficult. If we stay with Python 3.9, we need to create the capability to build Python from source (something we can do but I would rather not).

However, I'm saying not to panic -- but the fact is that none of us want t rely on something that isn't being maintained. If this isn't resolved soon, I suppose a few of us that need this to move forward could make a only-for-releases fork of the project.

I think a better plan would be to foster a true developer community around wxPython, with no single-person bottlenecks in any parts of the process. Unfortunately, that seems difficult at this time.

@infinity77 https://github.com/infinity77

It would also be nice to know if Robin is all right, we haven’t heard from him for a very long time. I hope he is, and maybe he’s just very busy with other things. Hopefully he hasn’t lost interest in wxPython. Andrea.

I believe he just pushed some changes to master a couple of days ago.

Ah, ok, thanks. It’s just that I’m an old timer and I was used to daily messages on the forum from him - I guess I was spoiled :-)

—

Reply to this email directly, view it on GitHub https://github.com/wxWidgets/Phoenix/issues/2128#issuecomment-1125689568, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACESNIO6CUBZTMXQRGCNTN3VJXWY5ANCNFSM5QZEIR2Q . You are receiving this because you were mentioned.Message ID: @.***>

[newville]

@ajkaijanaho @infinity77 @ChrisBarker-NOAA

Yes, I hope Robin is alright and glad to hear he has made some pushes.

@ChrisBarker-NOAA and @ajkaijanaho wrote

However, I'm saying not to panic -- but the fact is that none of us want t rely on something that isn't being maintained. If this isn't resolved soon, I suppose a few of us that need this to move forward could make a only-for-releases fork of the project.

I think a better plan would be to foster a true developer community around wxPython, with no single-person bottlenecks in any parts of the process. Unfortunately, that seems difficult at this time.

Multiple people are pushing to the master branch, PRs are being made, some are merged, and Issues are being closed. Development is definitely happening, which is encouraging. Thanks, @swt2c!

But also: it seems to me that highly-skilled C++ / wxWidgets abilities and familiarity with the C++ codebase are not the limiting factors for the issue here: building and pushing wheels to PyPI. The build scripts work to build wxPython wheels for Python 3.10 - the nightly builds, the conda packages, and some of the messages above demonstrate this can and will work. OK, maybe some backporting or tweaks would be needed for version 4.1.X, but in general, it should not be too much "real work" to generate and push a wheel. Or, if it is, that should be an issue to resolve.

Would it be reasonable for someone here (or multiple people even) to take on the role of "release manager" who can push the wheels for the tagged releases to PyPI?

[swt2c]

Yes Robin is okay, he's just been really busy with a new job. He's hoping to get back to wxPython 'soon'.

[ChrisBarker-NOAA]

@ajkaijanaho (and others):

Thanks for bringing up the binary release issue with older Python -- not sure how I missed that over all these years.

In fact, we have a lot of operational code running on Python 3.8 at this point, and somehow hadn't noticed that security fix binaries hadn't been released. But a suggestion:

Consider alternate source for binaries -- we make heavy use of conda-forge, which does indeed release binaries fo all security updates -- for example, Python 3.8.13 is the latest build of 3.8 at this point, whereas the 3.8.10 is the latest binary on python.org :-(

All the more reason why we need "proper" releases on gitHub, so that conda-forge and other third parties can build binaries for wxPython.

[swt2c]

All the more reason why we need "proper" releases on gitHub, so that conda-forge and other third parties can build binaries for wxPython.

What is wrong with the PyPI releases?

[newville]

All the more reason why we need "proper" releases on gitHub, so that conda-forge and other third parties can build binaries for wxPython.

What is wrong with the PyPI releases?

Wheels are not available for Python 3.10

[swt2c]

All the more reason why we need "proper" releases on gitHub, so that conda-forge and other third parties can build binaries for wxPython.

What is wrong with the PyPI releases?

Wheels are not available for Python 3.10

Right, but how would a GitHub release help that?

[ChrisBarker-NOAA]

A complete source release on PyPi is usually OK for third party distributors, yes. But sometimes those aren't wuite complete, which is why I like gitHub releases.

Looking now, the conda-forge recipe does pull from PyPi -- so that's fine.

My point is that a source release of some sort is very helpful, with or without binary wheel releases.

[newville]

@swt2c The title of this Issue is "Push 3.10 wheels to Pypi" ;).

Many downstream efforts (say, conda-forge, and maybe MacPorts, etc) will use a Github release to generate the appropriate package. A GitHub release is the signal of a release, and distribution packages (source and binary) will be built from those releases.

For PyPI specifically, it appears that only "robind" is the PyPI maintainer for wxPython. Maybe someone else could be added to the maintainer list?

[swt2c]

@newville I can read and am aware of what a release is.

[newville]

@swt2c great! It's easy for these kinds of conversations to go off in various directions, especially over time.
We're trying to be helpful, but it's kind of hard to see any actual route to a solution to this issue.
Is there something we can do to help make get releases pushed and packages distributed?

[newville]

@swt2c @RobinD42 This issue has been silent for 6 weeks, but I would like to ping this as it has not actually been resolved.

I'm very happy to see development, but the issue here is that there has not been a release of wxPython or wheels pushed to PyPI that work with Python 3.10 (released Oct 2021). Downstream packages that rely on wxPython being installed (either with conda or pip) cannot use Python 3.10, which is currently the only fully-supported version of Python.

(aside: not the issue here, but there is a conda package for 4.1.1 and Python 3.10, but it has problems that have been fixed in the development wxPython but still prevent my apps from working properly).

Snapshots are fine for testing and for developers to install by hand. They are not a practical method when listing wxPython as a dependency with a package manager (pip, conda, debian, MacPorts, etc).

Please recognize release and packaging as important tasks, separate from development. If there is something that we can do to help make get releases pushed and packages distributed, please let us know.

[Datamance]

Have to agree with @newville here. Can't pip install deeplabcut[gui] until this is fixed. Snapshots aren't the solution here.

[tyalie]

I also wanna add my salt here: As long as the version isn't in pip, I can't deploy them. I cannot demand from everybody that uses the software to compile wxPython themself, just to be able to use Python 3.10. In the latest Ubuntu LTS release, older Python versions aren't even in the package index anymore

[newville]

@tyalie thanks. I feel obligated to re-raise this issue too, and re-state to the developers @swt2c and @RobinD42 that if there is anything we can do to help get releases pushed and packages distributed, please let us know.

It's great to see that snapshot builds are being created: I see 4 snapshots in the past 30 days. Great! Still, that's not a tagged version in Github (which would take about 30 seconds to do and be very helpful for other packaging systems) or a version on PyPI (the issue as originally raised here). It is easy to believe that Python 3.10 will have been out for more than a year before a wxPython package for it is pushed to PyPI.

Several people have offered to try to help, and we've gotten effectively no response. That is worrying. It is also confusing: why would development be happening if there is no intention to release code or even to communicate with interested users when and how a release might happen?

I think it is past time to face the fact that something (I'm not sure what) is wrong here. Is it reasonable to fork this project simply in order to add tags and push to some repository (not unlike the wxPython310 one?) on PyPI? Would developers and others support such a fork?

[ChrisBarker-NOAA]

I can't seem to find out who has permissions to do releases on the project (e.g who the admins are) so we can reach out directly.

Are @swt2c and @RobinD42 it?

Anyway, if the folks with permission aren't responsive, then we don't really have a choice but to fork -- let me know if I can help out with that process. And it's not hard to dump the fork in the future if.when it becomes uneeded.

[swt2c]

Only @RobinD42 can make releases.

[swt2c]

wxPython 4.2.0 wheels have been pushed to PyPI (yay!).

[ChrisBarker-NOAA]

And a source TarBall -- yeah!

Thanks!!!!!!

[newville]

@RobinD42 Thanks very much! It would be easy to conclude that @swt2c closing this issue signals that a release was pushed, so the developers conclude that all is now good. Respectfully, I'm not 100% sure that it is. We all get that working on development and release is a ton of work and that a very tiny group of people are actually doing the work on a voluntary basis. Really, we're all very thankful.

And yet, this project seems to be both a "large-scale infrastructure" technology that many people depend on being robust and having a tiny number of actual developers and people who can generate releases. Really, we're all very thankful. And also: this project appears extremely fragile.

Coincidentally as of today, Python 3.11 rc1 is out. A similar delay in getting wxPython releases for Python 3.11 is definitely easy to imagine.

I've been using wxPython for about 20 years, and have ~60K loc of wxPython-using code that I maintain and support (sometimes poorly). I am in your debt, I am on your side. Please acknowledge the fragility, and let us all know how we can help reduce that fragility. Again, thanks.

[Porkepix]

wxPython 4.2.0 wheels have been pushed to PyPI (yay!).

@swt2c Any reason there are no wheels for Linux, only for Windows and mac though? I've been running into an issue caused by that, namely https://github.com/ddelange/pipgrip/issues/92 for which the maintainer explained the package needs to have its wheel on PyPi for it to work correctly on the target platform.

[swt2c]

wxPython 4.2.0 wheels have been pushed to PyPI (yay!).

@swt2c Any reason there are no wheels for Linux, only for Windows and mac though? I've been running into an issue caused by that, namely ddelange/pipgrip#92 for which the maintainer explained the package needs to have its wheel on PyPi for it to work correctly on the target platform.

There have never been Linux wheels on PyPI for wxPython. See here for more information and where you can get Linux wheels for certain distributions: https://wxpython.org/pages/downloads/

[Porkepix]

wxPython 4.2.0 wheels have been pushed to PyPI (yay!).

@swt2c Any reason there are no wheels for Linux, only for Windows and mac though? I've been running into an issue caused by that, namely ddelange/pipgrip#92 for which the maintainer explained the package needs to have its wheel on PyPi for it to work correctly on the target platform.

There have never been Linux wheels on PyPI for wxPython. See here for more information and where you can get Linux wheels for certain distributions: wxpython.org/pages/downloads

However not having them on PyPi breaks tool such as pipgrip, used to automate versions updates in tools like Homebrew for example. pipgrip's maintainer seemed to say it was something possible to do to have those portable builds, but that's way beyond my knowledge so I can only trust you if this is not something possible (for now, or forever).

[tyalie]

wxPython 4.2.0 wheels have been pushed to PyPI (yay!).

@swt2c Any reason there are no wheels for Linux, only for Windows and mac though? I've been running into an issue caused by that, namely ddelange/pipgrip#92 for which the maintainer explained the package needs to have its wheel on PyPi for it to work correctly on the target platform.

There have never been Linux wheels on PyPI for wxPython. See here for more information and where you can get Linux wheels for certain distributions: https://wxpython.org/pages/downloads/

Since that text was written a lot has changed thoo. Maybe this needs a renewed evaluation.

[ChrisBarker-NOAA]

However not having them on PyPi breaks tool such as pipgrip, used to automate versions updates in tools like Homebrew for example.

Odd -- wouldn't homebrew use the source tarball on PyPi? in any case, certainly not Linux wheels :-)

BTW -- conda-froge has attempted to rebuild with the new source tarballs. Unfortunately, it's failed -- I haven't lookng inot why yet. Hopefully someone will, I'm not the official maintainer anyway.

It's here if anyone is curious:

https://github.com/conda-forge/wxpython-feedstock/pull/84

[Porkepix]

However not having them on PyPi breaks tool such as pipgrip, used to automate versions updates in tools like Homebrew for example.

Odd -- wouldn't homebrew use the source tarball on PyPi? in any case, certainly not Linux wheels :-)

For the formula itself it does. But it uses pipgrip to pull the dependency list from PyPi and their versions and update the different dependencies in the formula; the dependencies themselves are installed from PyPi.

Also, Homebrew is available on Linux; it used to be named Linuxbrew and has since be merged with the main homebrew. Homebrew offer a set of commands such as brew bump or brew bump-formula-pr to help update easily formulas. That's where pipgrip is called, and from the maintainer's word (cf. the issue I linked) it looks like it relies on the wheel.

I ran brew bump --open-pr wxpython on a Linux computer, which in turn led to the issue I opened at pipgrip's repo, because /home/linuxbrew/.linuxbrew/opt/pipgrip/bin/pipgrip --json --tree --no-cache-dir wxPython==4.2.0 fails for the aforementionned reasons.

[ChrisBarker-NOAA]

Frankly, it seems pipgrip is not really the right tool to use for the job. If you're going to build a package from source, you really shouldn't be trying to get the dependencies from a binary wheel. And I would think Brew's dependencies would be inherently different anyway.

I'm not sure how conda-forge does it, but it does pull python dependencies[*], and I doubt it's looking at the wheels.

-CHB

[*] actually a conda recipe hard-codes the dependencies -- which it needs to, at least for packages that aren't pure python (and, now that I think about it for everything, as the conda name may not be the same as the PyPi name) -- but it does have a dependency analysis system that gives you a warning if the deps don't match, or seem to have changed.

[Porkepix]

Frankly, it seems pipgrip is not really the right tool to use for the job. If you're going to build a package from source, you really shouldn't be trying to get the dependencies from a binary wheel. And I would think Brew's dependencies would be inherently different anyway.

I'm not sure how conda-forge does it, but it does pull python dependencies[*], and I doubt it's looking at the wheels.

-CHB

[*] actually a conda recipe hard-codes the dependencies -- which it needs to, at least for packages that aren't pure python (and, now that I think about it for everything, as the conda name may not be the same as the PyPi name) -- but it does have a dependency analysis system that gives you a warning if the deps don't match, or seem to have changed.

Homebrew also kinda hardcode dependencies, see https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/wxpython.rb for example. But Python dependencies have their own specificities, and not every PyPi is packed into homebrew.

Can't talk for the homebrew maintainers, I'm not one, but if I had to do a guess, I think it's done using this tool to extract what the exact module versions are in the last distributed package so that it uses the exact same versions: pipgrip pull the dependencies and their versions for this exact version, and then download from PyPi the tarball for each of them so that it gets their url and their hash.

The whole thing allow for the tools to update each of these dependencies automatically without having someone to bother updating these dependencies one by one.

EDIT: Actually the wxpython formula isn't a good example for the automatic python dependencies update as it have none within right now. What I'm talking about is this kind of blocks: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/pipenv.rb#L27-L30 which are automatically updated on formula update.