Python 3 compatibility

[akittas]

Hi, Gooey is a great idea, I was wondering is it possible to add Python 3 compatibility for this project?

[piksel]

Unfortunatly, that is probably not going to happen before wxPython gets Python3 support. There is currently a project called Phoenix that attempt to do just that.
I tried to get Gooey working with the svn-builds of Phoenix and it kind of works:

I had to remove wx.animate and do some python3-porting. As soon as Phoenix is stable, making a py3 compatible version should not be too difficult.

[chriskiehl]

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 Wx would be moot, as client code would never interact with that side. The only Python code that clients would interact with would be (what I call), the "bindings," which is what generates the JSON that Gooey needs to run. And those would be crazy easy to port.

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.

[piksel]

@chriskiehl That sounds awesome!

[SethMMorton]

In the meantime, Gooey is written in a Python3 incompatible manner (the biggest example is the print statement as opposed to the print() fuction). Gooey could be modified to use python-version agnostic code so that the only thing preventing it from running on Python3 is the libraries, not the syntax.

[piksel]

There is basically only one place where we cannot have the same code for 2
and 3, and thats for opening a JSON file for parsing. In every other place
I've managed to do smaller changes to make the code valid in both py 2 and
3. But what is the point of doing that change when we may not even be able
to port it to python 3? I can commit the changes if Chris wants them.

On Sat, Feb 21, 2015 at 8:56 PM, Seth Morton notifications@github.com
wrote:

In the meantime, Gooey is written in a Python3 incompatible manner (the
biggest example is the print statement as opposed to the print()
fuction). Gooey could be modified to use python-version agnostic code so
that the only thing preventing it from running on Python3 is the libraries,
not the syntax.

—
Reply to this email directly or view it on GitHub
#65 (comment).

[shelper]

i just wonder if there is any progress on this issue?
thanks!

[chriskiehl]

@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...

[bilderbuchi]

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).

[bilderbuchi]

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.

[bilderbuchi]

RFC PR for py2/py3 compatibility is here: #131

[Kedrigern]

+1 for Python 3

[marshall-ucsd]

Since wxPython for Python 3.x is (still!) nowhere in sight...
What about using Tkinter as the GUI? Not as good as wxPython, but:

1. Included with all versions of Python, removing an external dependency
2. Supports Python 2.x and 3.x

[bilderbuchi]

There seems to be some movement lately, with a pledged bounty for the developer upon release of Phoenix, so I'm hopeful.
However, using Tkinter as the (default) GUI, maybe with options for other packages, sounds good to me. Don't know what effort that would entail, though, that's a question for @chriskiehl. I'm not sure if wxpython is not too entangled in the codebase for it to be easily switched out.
I'm prepared to re-do the work of #131 (preparation for py3 compatibility) to move towards that goal, should this go forward and be welcomed/merged.

[ghost]

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..". :/

[kcinnick]

Just here to formally express interest in a Python 3 compatible version :-)

[alexsanjoseph]

Same here. All the code that I have already done is in python 3, so I wish I could use this amazing extension!

[bosbyj]

+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.

[bosbyj]

Made some porting jobs, trying to pass all the tests.

C:\dev\gooey-future\Gooey (master)
> pytest
============================= test session starts =============================
platform win32 -- Python 3.4.2, pytest-3.0.6, py-1.4.32, pluggy-0.4.0
rootdir: C:\dev\gooey-future\Gooey, inifile: pytest.ini
collected 27 items

gooey\tests\test_argparse_to_json.py ................
gooey\tests\test_image_repositoy.py ...
gooey\tests\test_presentation.py FFF
gooey\tests\test_processor.py .....

================================== FAILURES ===================================
___________________________ test_presentation_init ____________________________

presentation_model = <gooey.gui.presenter.Presenter object at 0x03DD4170>

    def test_presentation_init(presentation_model):
      '''Sanity check that the primary fields are set on init '''
      presentation = presentation_model
>     presentation.initialize_view()

gooey\tests\test_presentation.py:50:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
gooey\gui\presenter.py:68: in initialize_view
    self.syncronize_from_model()
gooey\gui\presenter.py:78: in syncronize_from_model
    wx.CallAfter(self.syncronize_from_model_async)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

callableObj = <bound method Presenter.syncronize_from_model_async of <gooey.gui.presenter.Presenter object at 0x03DD4170>>
args = (), kw = {}, app = None

    def CallAfter(callableObj, *args, **kw):
        """
        Call the specified function after the current and pending event
        handlers have been completed.  This is also good for making GUI
        method calls from non-GUI threads.  Any extra positional or
        keyword args are passed on to the callable when it is called.

        :param PyObject callableObj: the callable object
        :param args: arguments to be passed to the callable object
        :param kw: keywords to be passed to the callable object

        .. seealso::
            :class:`CallLater`
        """
        assert callable(callableObj), "callableObj is not callable"
        app = wx.GetApp()
>       assert app is not None, 'No wx.App created yet'
E       AssertionError: No wx.App created yet

c:\python34\lib\site-packages\wx\core.py:2903: AssertionError

[bosbyj]

Gui window showed fine, but when you click on the Start button on footer, console logs error:

C:\dev\gooey-future\Gooey (master)
> example.py
C:\dev\gooey-future\Gooey\gooey\gui\imageutil.py:24: wxPyDeprecationWarning: Call to deprecated item ImageFromBitmap. Use bitmap.ConvertToImage instead.
  image = wx.ImageFromBitmap(_bitmap)
C:\dev\gooey-future\Gooey\gooey\gui\imageutil.py:30: wxPyDeprecationWarning: Call to deprecated item BitmapFromImage. Use :class:`Bitmap` instead
  return wx.StaticBitmap(parent, -1, wx.BitmapFromImage(image))
Traceback (most recent call last):
  File "C:\dev\gooey-future\Gooey\gooey\gui\windows\footer.py", line 104, in dispatch_click
    pub.send_message(str(event.GetId()))
  File "C:\dev\gooey-future\Gooey\gooey\gui\pubsub.py", line 23, in send_message
    event_handler(**kwargs)
  File "C:\dev\gooey-future\Gooey\gooey\gui\presenter.py", line 111, in on_start
    self.client_runner.run(command)
  File "C:\dev\gooey-future\Gooey\gooey\gui\processor.py", line 45, in run
    stderr=subprocess.STDOUT, shell=True, env=env)
  File "C:\Python34\lib\subprocess.py", line 858, in __init__
    restore_signals, start_new_session)
  File "C:\Python34\lib\subprocess.py", line 1085, in _execute_child
    args = list2cmdline(args)
  File "C:\Python34\lib\subprocess.py", line 663, in list2cmdline
    needquote = (" " in arg) or ("\t" in arg) or not arg
TypeError: argument of type 'int' is not iterable

I have done from builtins import str , but it didn't work.

[bilderbuchi]

@bosbyj have you seen #131, especially the PR description and the commit messages explaining what I did to get all test running (this was before Phoenix was available, though).
Btw, what version of W´xPython Phoenix are you running?

[bosbyj]

@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:

VERSION
    3.0.3.dev1830+0b5f910

[bilderbuchi]

@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?

[bosbyj]

@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.

[chriskiehl]

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!

[bilderbuchi]

Great news! 👍

[chriskiehl]

...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!

[bilderbuchi]

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...

[bosbyj]

Great progress! Congrats!!!!

[bosbyj]

Guys check this out ->
https://pypi.python.org/pypi/wxPython/4.0.0a1
Just discovered that wxpython now has py3k support.

[bosbyj]

Sorry to break silence, any news in July?

[chriskiehl]

@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 beep_boop.py in the new_hotness directory if ya wanted to play around with it. Still a bit rough at the moment (runs from a hard-coded json file), but the main pieces have been completed.

Remaining:

• final post-run screen
• Other stuff (progress bars, translations, polish, etc..)
• done

[bosbyj]

😁 lmao man, and thanks for the feedback! saludos cariñosos

[chriskiehl]

@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.

pip install -U git+https://github.com/chriskiehl/Gooey.git@2.0

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 -U flag it seems to fix everything. pip install -U PyQt5

Comments, hate, bug reports, or requests from anyone willing to give it a spin would be super awesome! 😁

[piksel]

Awesome! Those commits tho :D

[chriskiehl]

@piksel lol! Don't judge me! I follow the spam commits and rebase later methodology

[piksel]

@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...

[bilderbuchi]

Using pyside bindings instead could work around the license issue, it's MIT or LGPL if I remember correctly.

[chriskiehl]

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.

@piksel @bilderbuchi

😩 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:

• all projects that use Gooey now have the same licensing woes.
• packaging a gooey project now requires a commercial PyQt license

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 pip.

3. something else

Plz halp.

[bilderbuchi]

@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? :-)

[piksel]

@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?

[chriskiehl]

Closing this as Gooey is compatible with Python 2/3 now ^_^

[bilderbuchi]

Hooray! Many thanks! :party:

[bosbyj]

Great job! Been all through this issue~~~