-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python 3 compatibility #65
Comments
Another option, which is what Gooey is heading towards (so that it works with more than just Python), would be to run the actual GUI side of things as an isolated executable -- something packaged with, say, PyInstaller. Then python 3 compatibility with Whenever Phoenix is stable, Gooey will migrate. In the mean time, it'll be (eventually) optionally served as an executable so people can still use whatever python version they please. |
@chriskiehl That sounds awesome! |
In the meantime, Gooey is written in a Python3 incompatible manner (the biggest example is the |
There is basically only one place where we cannot have the same code for 2 On Sat, Feb 21, 2015 at 8:56 PM, Seth Morton notifications@github.com
|
i just wonder if there is any progress on this issue? |
@shelper Unfortunately not. : ( Noticing that the last time I commented on this issue was February (oy..), I figure I'll at least explain the slow output on Gooey: In short, I (briefly!) thought I liked money more than I liked free time. So, I accepted some side contract work. This has left little time for leisure programming on Gooey. There's still a giant list of things to be done, but alas! Currently a bit bogged down... |
I guess at least the changes for Py3 compatibility that @piksel proposed to PR would be a good idea in the meantime? This will be needed anyway, and will maybe even help with any subsequent changes like refactoring the GUI side, or starting testing with Phoenix snapshots (which seems to be available nowadays). |
I plan to sometime soon take a shot at converting the codebase to py2+py3 using future, if that would be a welcome change? I think it's necessary at some point in the future, anyway, and hopefully it eases the transition away from a wxwidgets/Phoenix-only solution. |
RFC PR for py2/py3 compatibility is here: #131 |
+1 for Python 3 |
Since wxPython for Python 3.x is (still!) nowhere in sight...
|
There seems to be some movement lately, with a pledged bounty for the developer upon release of Phoenix, so I'm hopeful. |
I really wish projects that only supported Python2 would say so up front. Like, instead of "Turns a Python Script into.." it would say "Turns a Python 2 Script into..". :/ |
Just here to formally express interest in a Python 3 compatible version :-) |
Same here. All the code that I have already done is in python 3, so I wish I could use this amazing extension! |
+1 for python3. Great tool! Just fiddled around some scripts for friends, but had many unicode issues again from py2. Don't want to suffer that anymore. I would be glad to help to port Gooey to py3. |
Made some porting jobs, trying to pass all the tests.
|
Gui window showed fine, but when you click on the Start button on footer, console logs error:
I have done |
@bilderbuchi Hi! Didn't read that page but I pretty much followed the same way to get the GUI showed up under py3. I am using a quite old version:
|
@chriskiehl now that wxpython phoenix seems to be available in a usable state, would you welcome contributions towards integrating wxpython and python 3 compatibility? I am asking because in TODO.md in the 2.0 branch I see "Deprecate WxPython" - does that mean you will remove it (soon), in which case it doesn't make sense to invest the effort of porting? |
@bilderbuchi Seems that the owner is pretty busy nowadays. I will be available if this project starts to move to 2.0 with pyqt. It is just a matter of changing the frontend stuff. |
Busy indeed :( However I did spend last weekend chipping away at it. I've got a local branch with all of the Gooey widgets (choosers, dropdowns, etc..) re-implemented in PyQt5. The old wx code is the hottest of garbage, so I've been rebuilding from scratch versus just swapping out wx components for Qt ones and duct taping it together. I'll push what I have in a few days or so! |
Great news! 👍 |
...By "push what I have in a few days", I apparently meant "push what I have in several days to a few weeks". I got pulled away on other things for most of the week/weekend. But I did manage to get Gooey running in a basic form on Python3 with Pyqt5 tonight 😄 "I'll push what I have over the next few weeks...." Looks more or less the same, but... Pyqt! |
Well that's much of the way there already, right? 😁 That's the frustrating thing about refactoring, in the end you don't see a difference... |
Great progress! Congrats!!!! |
Guys check this out -> |
Sorry to break silence, any news in July? |
@bosbyj https://www.youtube.com/watch?v=0d6yBHDvKUw 😁 You can track commit progress on this branch: https://github.com/chriskiehl/Gooey/commits/2.0. Currently runs via Remaining:
|
😁 lmao man, and thanks for the feedback! saludos cariñosos |
@everyone 2.0 branch is officially in a previewable/runnable state. It's missing the progress bar and the radio widget, but most everything else is there. If you're running Python >= 3.5, you should be able to just pip install it and be on your way. All deps should auto resolve.
Note! if you get a failure and a super weird exit code when you try to run anything using the Gooey decorator, it's most likely PyQt silently and violently barfing. It seems to get corrupted when its installed as part of Gooey's setup.py. Haven't figure that piece out yet. However, If you just manually re-install it with the Comments, hate, bug reports, or requests from anyone willing to give it a spin would be super awesome! 😁 |
Awesome! Those commits tho :D |
@piksel lol! Don't judge me! I follow the spam commits and rebase later methodology |
@chriskiehl You depend on v5.7 of PyQt5 which seems broken. My PyQt5 dependent code worked before installing gooey2 and stopped working until I upgraded it to 5.9 (latest). Do you want pull requests? Also on another note, PyQt5 is GPL but Gooey is MIT, is that going to be a problem? I'm not sure about how GPL "linking clause" works with PIP and python... |
Using pyside bindings instead could work around the license issue, it's MIT or LGPL if I remember correctly. |
Edit: Looks like I misunderstood the state of wxPhoenix. They're publishing wheels to PyPi. So, it looks like it'll be merging #197, deleting 2.0, and calling it a day. 😩 I finally worked up the energy to explore this topic. It's pretty demoralizing, as there doesn't seem to be a clear path forward. Library Options for keeping MIT License: Pyside doesn't look viable at the moment. It's current stable build doesn't have python 3 support, and its next version, Pyside2, is in such a state that it still needs to be build from source, which would make Gooey super hard to actually use. Further, the exact knowledge of how to actually build the project on all the major platforms seems lacking, to say the least. So, that's yet another hurdle for people who want to use Gooey. GPL aside, one of the things I really dig about PyQt is that it's published as a wheel. So, Gooey can actually be pip installed without any separate out-of-band steps required (which is awesome). WxPhoenix To stick with the current license, I'm pretty much still stuck waiting for WxPhoenix, which has the same problem as Pyside2: building from source. It also means abandoning all of the 2.0 work which, well, kinda kills my motivation. Alternative Licensing 1. Gooey moves to GPL / dual license Downstream effects:
If I went this route, based on this stackexchange question, making the move will involve getting an OK from all 41 Gooey contributors. If one of them doesn't respond, or if one disagrees, it can't be re-licensed. Although, from reading the contributions section on github all contributions are made under the same license as the projects. So, maybe that means the license can be changed without tracking down permission from each person..? Adding to the complexity, it's actually need to be approval for two different licenses. A dual license would be needed so that people who are willing to pay for a copy of Qt can also use a Gooey license that allows them to package things free from GPL restrictions. 2. I buy a Qt license, Gooey's core internals become closed source, and only binaries and bindings are distributed This is what the PyQt folks suggested in an email. A commercial license allows you to distribute binaries. All Qt code would be moved to a separate project and, somehow, probably through magic, the MIT licensed source along with pre-built binaries are delivered via 3. something else Plz halp. |
@chriskiehl awesome that you've got some momentum! Regarding relicensing: ianal, but I'm pretty sure you still have to get permissions from every contributor. They licensed their contribution under the license of the repo at the time of the contribution, so if some of their code is still in the repo, of course you have to ask if you want to change the license for their contribution. Licensing option 3: one suggestion would be to merge the wxpython stuff and achieve py3 compatibility. Then, considering your limited time available for this project, you could invest any spare energy you have (after bug fixes and or reviews, I guess) into slowly abstracting away and generalizing the GUI toolkit interface, with the current/planned interface of pyside2. This is gonna take quite some time, so hopefully by the time that is finished, pyside2 will be polished enough that you can start using it. Does that sound reasonable? :-) |
@chriskiehl Yeah, dealing with GPL can be tough. I hate it whenever I realized a library I've used isn't LGPL as I thought but rather GPL and impossible to license (reasonably). Using wxpython4 seems to be the least painful way to go. Maybe the current 2.0 branch could be kept for a future pyside fork? |
Closing this as Gooey is compatible with Python 2/3 now ^_^ |
Hooray! Many thanks! :party: |
Great job! Been all through this issue~~~ |
Hi, Gooey is a great idea, I was wondering is it possible to add Python 3 compatibility for this project?
The text was updated successfully, but these errors were encountered: