Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Python2 -> Python3 (once more) #498

Open
sunweaver opened this issue Sep 23, 2019 · 35 comments
Open

Python2 -> Python3 (once more) #498

sunweaver opened this issue Sep 23, 2019 · 35 comments

Comments

@sunweaver
Copy link

Hi,

my name is Mike Gabriel, I am a Debian Developer and I was asked by the lead developer of Ubuntu Mate (Martin Wimpress) to bring this software to Debian and Ubuntu.

Unfortunately, I can't do this, as this project is still stuck with Python2. The Debian people are currently in the process of removing all Python2 packages from the distro with the goal to release Debian 11 in 2 years from now without Python2.

As of this, it is policy-wise forbidden since June 2019 to upload Python2 depending software to Debian. Please note that Python2 upstream is EOL in January 2020.

I noticed Python2 -> Python3 issues having been closed in the past with a "not gonna happen" kind of statement as the justification.

This issue report is to reconsider this tenor.

Thanks+Greets,
Mike
@kozec
Copy link
Owner

kozec commented Oct 12, 2019

Hello,

there is only one Python2 -> Python3 issue, #367, and it should still be open. Nevertheless, your reading of "not gonna happen" is correct.

I'm currently in the process of rewriting "core" of SC-Controller into C, with code in c branch already being able to do big part of what Python code does. Thanks to that, I'm able to port SC-Controllers to systems that doesn't have issues like policy you've described.

Once "core" is finished, I'll have to decide if, and to what toolkit and language GUI part should be ported, but considering entire Py2/3 fiasco, Py3 is out of question. Since I'll have to bundle python interpreter on Windows anyway, bundling Py2 interpreter there and relying on availability of Py2 elsewhere looks like simplest solution.

Your distro deciding to drop Py2 support is indeed unfortunate, but it's not something I can influence in any way.

@sunweaver
Copy link
Author

sunweaver commented Oct 21, 2019 via email

@Jacalz
Copy link
Contributor

Jacalz commented Oct 28, 2019

A lot of distrubutions are aiming at removing python2 soon due to it going EOL next year. Still using python 2 will have the probability of bringing security concerns. I know for a fact that the diro that I'm using (Solus) are starting to deprecate stuff and when they are fully ready, everything that hasn't moved on will be dropped from the repo.

@DanielJoyce
Copy link

DanielJoyce commented Oct 30, 2019 •
edited
Loading

Uhhh, Python2 is reaching EndOfLife, and will see no further development across the board.

https://www.python.org/doc/sunset-python-2/

So its not just a distro decision, its a Python.org decision. It will be deprecated / on life support everywhere.

What will happen if I do not upgrade by January 1st, 2020?

If people find catastrophic security problems in Python 2, or in software written in Python 2, then most volunteers will not help fix them. If you need help with Python 2 software, then many volunteers will not help you, and over time fewer and fewer volunteers will be able to help you. You will lose chances to use good tools because they will only run on Python 3, and you will slow down people who depend on you and work with you.

Some of these problems will start on January 1. Other problems will grow over time.

Basically no more security fixes, etc, by other package maintainers. Its dead.

@DanielJoyce
Copy link

DanielJoyce commented Oct 30, 2019 •
edited
Loading

You can be stubborn all you want, but if you're wanting to ship python 2, you're pretty much gonna have to compile it yourself. As for fiasco, py2 being retired has been the plan since py3 was released. Its been what, a decade now?

@Seil0
Copy link

Seil0 commented Oct 31, 2019

Hi,
I'm maintaining the openSUSE experimental sc-controller package at games:tools. As @sunweaver and @Jacalz said it's a major problem relying on python 2.

@rnhmjoj
Copy link

rnhmjoj commented Oct 31, 2019

If no one intends to port it to python3 a possible solution could be what the Oil shell does: taking a stripped down python2 interpreter with dependencies and bundle all of it in the project tree.

@KAMiKAZOW
Copy link

taking a stripped down python2 interpreter with dependencies and bundle all of it in the project tree

Bundling End-of-Life software is hardly a good idea.

@Seil0
Copy link

Seil0 commented Nov 5, 2019

If no one intends to port it to python3 a possible solution could be what the Oil shell does: taking a stripped down python2 interpreter with dependencies and bundle all of it in the project tree.

I think that's a problem for most linux distributions.

@DanielJoyce
Copy link

DanielJoyce commented Dec 4, 2019 •
edited
Loading

Currently porting to python3. The biggest issue is string encodings, but making steady progress.

Also JEDI caught a few bugs here and there.

Edit: Getting down to brass tacks I think.

Edit: Time to run and fix the tests, and break out a controller for testing. Found a missing dependency too for the builds.

Edit: Appindicator stuff seems kinda busted, especially on Linux/Gnome. Icon not showing, but dropdown works. Icon is blank right now. Still tracing that down. May just focus on tests for now, and leave that as todo. Build scripts aren't very bullet proof.

Also, lots of encoding changes, and windows will be fun because by default it tends to not use utf-8, so I suspect when I get something usable, that debugging that may be the most fun.

edit: Everyone has been sick at home. Checkout my username for fork branch

@MadeOfMagicAndWires
Copy link

@DanielJoyce Thanks a bunch, I'll try it out! Maybe consider submitting a PR.

@toby63 toby63 mentioned this issue Apr 1, 2020
Open
@Patola
Copy link
Contributor

Patola commented May 4, 2020

I did not know about this problem with python2 and ended up opening a bug report at Ubuntu's launchpad: https://bugs.launchpad.net/ubuntu/+source/python-pylibacl/+bug/1876350

@DanielJoyce have you given up on your attempt? Your fork seems the same for at least 6 months ago, yours don't even have the 0.4.9.10 release from Dec 25, 2019 from @kozec

Please don't let this software die. I know the steam controller has been stopped but I still find it the best controller ever. I have 132 different configurations for it currently, and I don't think Steam's driver is as good as kozec's.

@Ryochan7
Copy link
Contributor

Ryochan7 commented May 9, 2020

@Patola His port is kind of hidden. The upgrade-to-python3 branch is listed in stale branches on the fork but I ended up finding it via the Network Graph. The current port did not work for me anyway. The GUI comes up but it cannot detect my controller. Also, that fork has not been updated since 2019/12/07.

https://github.com/DanielJoyce/sc-controller/tree/upgrade-to-python3

I ended up spending some time last night to attempt to get it working on my own; I found the upgrade-to-python3 branch after the fact. I have a mostly working build of version 0.4.7 running under Python 3.7.7 on Fedora 31. Device detection works, the mapper works, and most portions of the OSD work; getting the keyboard working properly was a pain. Hotplugging devices does not seem to work.

I need to properly fork this repo and make a new branch with these changes.

@sunweaver
Copy link
Author

sunweaver commented May 9, 2020 via email

@Ryochan7
Copy link
Contributor

Ryochan7 commented May 10, 2020 •
edited
Loading

Got the current master branch code ported to Python 3. It can still use some work but it is usable in its current state.

https://github.com/Ryochan7/sc-controller/tree/python3

Update 2020/05/10: A few more bugs fixes have been made. Profile exporting works. Also, device hotplugging works now.

@Patola
Copy link
Contributor

Patola commented May 11, 2020

Wow... Thank you, guys. Will test it ASAP.

@Seil0
Copy link

Seil0 commented May 13, 2020

@Ryochan7 Thank's for your work. I was able to test it and found a few issues with the daemon, but i was able to fix them. Would you like me to open a pr at your repository?

@Ryochan7
Copy link
Contributor

Ryochan7 commented May 23, 2020 •
edited
Loading

@Seil0 Sure thing

I got the KeyGrabber class fixed. Ended up migrating some of my old custom changes; those will only be available as a Gist later. The experience is better and I hope to finally beat some games in my Linux backlog.

Updated Gist.

sccchanges_20200523.diff:
https://gist.github.com/Ryochan7/316a644935f33e4f51ee19058c79777c

@blooalien
Copy link

This frankly just makes me sad. This was by far the very best controller configurator/driver I have found, not only for my Steam controller, but for controllers in general. Has one of the Python3 forks been settled upon as the best option going forward? Which one should I switch to if I wish to continue using SC-Controller, but cannot continue using Python2 much longer? Ryochan7's fork perhaps?

Personally, I still don't understand the stubbornness surrounding the Python2 to 3 transition. I've been using Python3 for ages now, and literally the only issues I've had with Python3 thus far has come down entirely to a rare few developers bein' stubborn like this. In every other respect, Python3 has been a fantastic experience for me compared to Python2.

@Ryochan7
Copy link
Contributor

Ryochan7 commented Jun 5, 2020

The DanielJoyce fork didn't work for me when I tested it. At this time, it looks like my fork is the main Python 3 compatible fork of sc-controller. I plan on continuing working on the Python 3 fork for a while and keep the code in sync with this upstream master branch. It will be a okay stopgap measure until the c branch version is more full featured.

sc-controller has been the only piece of software that has made the Steam Controller a viable Xbox 360 controller alternative for me; even Steam Input didn't do what I wanted. I have wanted to get more use out of my Steam Controller again but Fedora switched to using Python 3 for the default Python installation. I would have hoped somebody else in the community would have taken a more active part beforehand rather than expecting Kozec to drop his current work though.

I would consider contributing a bit to the development of the c branch version but I cannot get the current c branch version to run; I can get version 0.4.9.10 built and running though. I will have to keep trying.

@sunweaver
Copy link
Author

sunweaver commented Jun 5, 2020 via email

@Ryochan7
Copy link
Contributor

Ryochan7 commented Jun 8, 2020

Would you be ok with being an upstream for Debian regarding the sc-controller fork?

As long as Kozec has no problem with it then it is fine. I would probably hold off until at least the pull request from strycore is merged. For the most part, only Steam Controller support works. Support for other controller types still needs to be fixed.

Also, after a lot of struggling, I finally got the current c branch program running. Some of my problems were attributed to updates to MSYS2 that the release script does not take into account. Some libraries needed to be added to the release folder in order for libgtk-3-0.dll to load.

tschoonj/GTK-for-Windows-Runtime-Environment-Installer#24

One other significant problem is due to PyGObject no longer supporting Python 2. As long as sc-controller keeps using Python 2, PyGObject will have to be frozen at version 3.34.0 and it will have to be installed with pip.

@Ryochan7
Copy link
Contributor

Ryochan7 commented Jun 9, 2020

Got the changes from strycore, and others, merged into the python3 branch

@Patola
Copy link
Contributor

Patola commented Jun 9, 2020

Did it work for you? I tried to clone your repository, checked out the python3 tree, then built the appimage. But then:

[9:54] [9281] [patola@risadinha sc-controller]% ./SC_Controller-x86_64.AppImage&
[1] 42210
[9:54] [9282] [patola@risadinha sc-controller]% Traceback (most recent call last):
  File "/tmp/.mount_SC_Cono43XTU/usr/bin/scc", line 6, in <module>
    from scc.scripts import main
  File "/tmp/.mount_SC_Cono43XTU/usr/lib/python2.7/site-packages/scc/scripts.py", line 125
    print("Unknown profile:", argv[1], file=sys.stderr)
                                           ^
SyntaxError: invalid syntax

(zenity:42219): GdkPixbuf-WARNING **: 09:54:58.968: Cannot open pixbuf loader module file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.

(zenity:42219): Gtk-WARNING **: 09:54:59.275: Failed to set text 'Traceback (most recent call last):
  File "/tmp/.mount_SC_Cono43XTU/usr/bin/scc", line 6, in <module>
    from scc.scripts import main
  File "/tmp/.mount_SC_Cono43XTU/usr/lib/python2.7/site-packages/scc/scripts.py", line 125
    print("Unknown profile:", argv[1], file=sys.stderr)
                                           ^
SyntaxError: invalid syntax' from markup due to error parsing markup: Error on line 7 char 37: Element “markup” was closed, but the currently open element is “module”

(zenity:42219): GdkPixbuf-WARNING **: 09:54:59.304: Cannot open pixbuf loader module file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.

(zenity:42219): Gtk-WARNING **: 09:54:59.304: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.

(zenity:42219): GdkPixbuf-WARNING **: 09:54:59.305: Cannot open pixbuf loader module file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/48x48/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Bail out! Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/48x48/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
/tmp/.mount_SC_Cono43XTU/AppRun: line 23: 42219 Aborted                 "$@"

[1]  + exit 1     ./SC_Controller-x86_64.AppImage

@Patola
Copy link
Contributor

Patola commented Jun 9, 2020

I created a symbolic link from /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0 to /usr/lib/gdk-pixbuf-2.0 but the application still fails:

[10:03] [9302] [patola@risadinha sc-controller]% ./SC_Controller-x86_64.AppImage 
Traceback (most recent call last):
  File "/tmp/.mount_SC_ConbPZI7m/usr/bin/scc", line 6, in <module>
    from scc.scripts import main
  File "/tmp/.mount_SC_ConbPZI7m/usr/lib/python2.7/site-packages/scc/scripts.py", line 125
    print("Unknown profile:", argv[1], file=sys.stderr)
                                           ^
SyntaxError: invalid syntax

(zenity:42741): Gtk-WARNING **: 10:03:11.241: Failed to set text 'Traceback (most recent call last):
  File "/tmp/.mount_SC_ConbPZI7m/usr/bin/scc", line 6, in <module>
    from scc.scripts import main
  File "/tmp/.mount_SC_ConbPZI7m/usr/lib/python2.7/site-packages/scc/scripts.py", line 125
    print("Unknown profile:", argv[1], file=sys.stderr)
                                           ^
SyntaxError: invalid syntax' from markup due to error parsing markup: Error on line 7 char 37: Element “markup” was closed, but the currently open element is “module”

@rnhmjoj
Copy link

rnhmjoj commented Jun 9, 2020

@Patola are you running it with python2?

@Ryochan7
Copy link
Contributor

Ryochan7 commented Jun 9, 2020

Did it work for you? I tried to clone your repository, checked out the python3 tree, then built the appimage. But then:

@Patola I would assume that it is trying to use Python 2. I guess the next task would be to try to update the appimage build script to take Python 3 into account.

@Ryochan7
Copy link
Contributor

It took some work but I got the AppImage version to work properly again. Quite a few changes needed to be made to get the AppImage version working. The AppImage version has been tested on Fedora 32, Manjaro 20.0.3, and Xubuntu 19.10. Hopefully it works fine on other distros as well.

SC_Controller-x86_64_20200613.AppImage
https://drive.google.com/file/d/1l4I_Rnt092e2Zfqw_edLFcZtm54g9jpo/view?usp=sharing

@Patola
Copy link
Contributor

Patola commented Jun 13, 2020

Just tested this appimage, it's not working for me on Ubuntu 20.04. When it starts, if I have the steam controller on, it turns it off. If I turn it on again, it is not recognized. And when I exit the program, it seems to reset my USB subsystem, making my USB mouse become unresponsive.

In contrast, the regular sc-controller python2 appimage works correctly and does not do any of this.

@Ryochan7
Copy link
Contributor

I tested the AppImage on a vanilla install of Ubuntu 20.04 and it worked for me. Although, support for vanilla Ubuntu 20.04 and later doesn't matter that much to me. As long as snapd remains proprietary, I will not recommend Ubuntu to anyone anymore. At least derived distros like Linux Mint are making snap an optional component.

@xordspar0
Copy link

support for vanilla Ubuntu 20.04 and later doesn't matter that much to me. As long as snapd remains proprietary, I will not recommend Ubuntu to anyone anymore.

Snapd is not proprietary. It's here on GitHub, licensed under the GPL v3: https://github.com/snapcore/snapd

@Ryochan7
Copy link
Contributor

I was mistaken about which portion is proprietary. The backend server is proprietary but the client side program is not.

@Ryochan7
Copy link
Contributor

Ryochan7 commented Jul 8, 2020

Updated AppImage with the GtkHeaderBar tweak to remove the duplicate window icon when run on Plasma. Also, merged the DS4 v2 udev rule from upstream.

SC_Controller-x86_64_20200707.AppImage:
https://drive.google.com/file/d/16QHJ4d5eaCYCYPdmFQ96DWJLh81L7gX8/view?usp=sharing

@khumba khumba mentioned this issue Jul 23, 2020
Closed
@DanielJoyce
Copy link

Looks like Ryochan7 took over.

Anyways, yes, the main dev branch for my work was https://github.com/DanielJoyce/sc-controller/tree/upgrade-to-python3

This had a lot of upgrades and updates pulled in. But its kinda stale by now.

@Patola
Copy link
Contributor

Patola commented Aug 18, 2020

So... Whose build should we use?

jtojnar added a commit to NixOS/nixpkgs that referenced this issue Oct 18, 2020
@jtojnar
sc-controller: mark as broken
149c7f0 
Python 3 is not supported but PyGObject no longer supports Python 2.

kozec/sc-controller#498
jtojnar added a commit to NixOS/nixpkgs that referenced this issue Oct 23, 2020
@jtojnar
sc-controller: mark as broken
eaeafe6 
Python 3 is not supported but PyGObject no longer supports Python 2.

kozec/sc-controller#498
@orivej orivej mentioned this issue Nov 13, 2020
Merged
10 tasks
@Ryochan7 Ryochan7 mentioned this issue Nov 14, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests