Push 3.10 wheels to Pypi #2128
Comments
|
There is a (official) wxpython310 package on pypi.org. I don't know if the 310 postfix is intended... |
|
@hoba87, I'm not sure, but I can tell you first hand that typing pip install wxpythonon python 3.10.2 still doesn't work, so I assume it wasn't included. |
That's not an official wxPython package. |
Oh sorry, it just looked like, because it seems to be a clone of the official package. |
|
@TheQuinbox as said above, nothing official, but if you want to try: https://pypi.org/project/wxPython310/ |
|
I would recommend the snapshot builds instead: |
|
@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. |
|
@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. |
|
Can follow the steps for compile wxPython in Python 3.10 or download the wheel |
|
@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 -- The result is that those of us writing downstream libraries or applications must use custom install scripts or other packaging systems (say, 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. |
|
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. |
I do not see any x86 builds for python 3.10.x |
|
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. |
|
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 :-( |
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/
Yes, the lack of releases is a concern. The lack of wheels is a more immediate issue for us. |
|
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 |
|
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
<#2128 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACESNIOUKH46WCLV4XXFOZLVJUV63ANCNFSM5QZEIR2Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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).
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.
I believe he just pushed some changes to master a couple of days ago. |
|
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
<#2128 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACESNIO6CUBZTMXQRGCNTN3VJXWY5ANCNFSM5QZEIR2Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@ajkaijanaho @infinity77 @ChrisBarker-NOAA Yes, I hope Robin is alright and glad to hear he has made some pushes. @ChrisBarker-NOAA and @ajkaijanaho wrote
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? |
|
Yes Robin is okay, he's just been really busy with a new job. He's hoping to get back to wxPython 'soon'. |
|
@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. |
What is wrong with the PyPI releases? |
Wheels are not available for Python 3.10 |
Right, but how would a GitHub release help that? |
|
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. |
|
@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? |
|
@newville I can read and am aware of what a release is. |
|
@swt2c great! It's easy for these kinds of conversations to go off in various directions, especially over time. |
|
@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. |
|
Have to agree with @newville here. Can't |
|
I also wanna add my salt here: As long as the version isn't in pip, I can't deploy them. |
|
@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? |
|
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. 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. |
|
Only @RobinD42 can make releases. |
|
wxPython 4.2.0 wheels have been pushed to PyPI (yay!). |
|
And a source TarBall -- yeah! Thanks!!!!!! |
|
@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. |
@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: |
However not having them on PyPi breaks tool such as |
Since that text was written a lot has changed thoo. Maybe this needs a renewed evaluation. |
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: |
For the formula itself it does. But it uses 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 I ran |
|
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: 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 |
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.
The text was updated successfully, but these errors were encountered: