inkscape: Port to Python 3

For the person who wants to work on this:
Some (a lot of?) work on this has already been done by su_v:
https://gitlab.com/su-v/inx-fork

(not sure about current status)

Matthias, I dropped the usb seed and I did a tasksel upload that I think dropped the usb task. I don't see any reverse-depends for the inkscape in main. Can you figure out why inkscape is still in main but is not showing up on the component mismatches report?

now demoted

While I think it is fine for Inkscape to not be in main, there is a snap for it, if there are those who want to still see it in main another possible solution is to split out the Python extensions. They're independent and could be a separate package with a recommends.

@Hachmann - Thanks for the gitlab link to su_v's work. Do you know what the status of the fork is? Is there a wiki page/bug report tracking the migration?

It would be good to get this merged as soon as possible, as the fork is 6 months behind master.

@valavanisalex Sorry, I don't know much about it. su_v is often around on IRC, please ask her there about the status or send her an email. As far as I know, there is no other place tracking this.

Do you think this might become one focus for the Hackfest? Being 'demoted' doesn't sound so good in my ears, tbh.

(Found this only by chance, I definitely need to remember to subscribe here when I comment...)

I'd second Ted's suggestion of splitting out python code to a separate package, that's something we've been pondering doing for other reasons already.

Do we have a listing of what exactly uses python?

I know the extension programs do, and those could be split out to an inkscape-extras package.

If there are any utilities or build helpers in python, those should be redoable in python3 without much fuss. Give me a list and I can make sure they all get done.

Is there anything else besides that? Does Inkscape have any python bindings internally that are version specific?

@moini, being demoted from main isn't that big of a deal, it's more a loss against Ubuntu than Inkscape itself. Most users will have universe enabled so it's not going to impact them. It just limits Canonical's ability to make good use of Inkscape in their own products. Like Ted points out, users have many ways to get Inkscape.

The main → universe move as I see it has more of a logistic change: theoretically speaking, as long as it is in main Canonical could be called upon providing commercial support if any customer asked for it, as well as providing security patches if any security breach appeared, etc.
At any rate, yes, nothing to be concerned about: actually using a Ubuntu desktop without universe is just plain impossible anyway.

Thank you for the explanation, Bryce and Mattia! But until 2020, this should be solved, as far as I understand, regardless of this? We've only got 2 hackfests until then... time flies.

I found that these depend on python scripts, but there may be more, hope others will fill in the blanks (I've also got no clue of how easy or hard it's to port these):

- several python export and import routines (that use extensions, e.g. save as optimized SVG via scour (how's scour doing with Python3, @Eduard?), dxf. What about uniconvertor? Does it have a python3 version?... We don't include it, but it needs to work with the rest... :-/ Or I think there was talk about dropping it...?

- the customizable templates (those with dots in the 'New from Template' dialog).

- everything aside from Tutorials in the Help menu (probably very quick to port, if anything needs to be done at all)

- couldn't find what 'prepare_file_save_as.py' is currently used for, weirdly - but I think it was needed for export to dxf...

- there seem to be several i18n-generation scripts in various subdirectories of the /share/... directory tree - guess they are used to internationalize the svg files (filters, markers,...) there

- several packaging scripts, for win and some Cmake scripts

- (extension tests)

- dpi switcher extension (not needed when opening files, intended for switching manually later)

One thing we'd need to consider is that some more or less basic Inkscape functionality currently relies on Python extensions, e.g.
- Several templates
- Help links
  although I already wondered if this was even really necessary -
  I assume there are better solutions available to open a link from GTK
- Export/Import extensions
  They are not strictly Inkscape core but a lot of users are not aware
  they might be running an extension to export to their favorite format.

Second important questions is if this would only affect packaging or if we really want to split out the extension code from the Inkscape source repository into a more or less self sufficient sub-project.
In the latter case I fear that the bundled extensions - which are in a pretty desolate state even now - might bit-rot even faster (less users, less developers having the repo on their radar, less obvious affiliation with the core program).
If we could achieve to make the extensions into a "community project" (that is a lot more user driven, allowing easy contributions and additions of new extensions with well-organized categorization and documentation) that could also improve upon the status-quo but as a start this would require a "core team" of people who would be willing to do the necessary maintenance (not sure we have that right now...).

Status changed to 'Confirmed' because the bug affects multiple users.

Some work has been done on this by doctormo during the Hackfest, as far as I understand.
However, the Python3 port has been combined with moving extensions out of the main repo for that branch, so not sure about compatibility and usefulness with/for current Inkscape versions.

Inkscape 0.92.5 as well as Inkscape 1.0 will be compatible with Python 3:

0.92.5:
https://gitlab.com/inkscape/inkscape/merge_requests/568
https://gitlab.com/inkscape/inkscape/merge_requests/582

1.0:
https://gitlab.com/inkscape/extensions/blob/master/README.md

What is the ETA for 0.92.5?

Last month. [Meaning: sorry, no idea, it was due much earlier, but hasn't been released yet, will probably be before August]

There are still a few calls to "python ... i18n.py" in share/*/CMakeLists.txt, so the build system still requires python2.

The 5 scripts share/*/i18n.py itself are compatible with both python2 and python3.

What's the problem with calling "python" (without version number)?

If there's no version number, it's supposed to be the system's preferred version of python (which might well be python3).

Therefore I don't see an explicit dependency on Python 2, as long as all build scripts are compatible with Python 3.

The problem is that in the Linux world there is no real, final, decision on what to do with the name "python". So, at least in Debian/Ubuntu, we have no plans on having /usr/bin/python to ever
 point to anything that is not Python 2. In Arch Linux, the situation is the opposite instead…

There is https://www.python.org/dev/peps/pep-0394/ that tried to reach a conclusion, but it actually caused even more confusion, so the world is all in flux.

Having said that, if you explicitly write "python3" you are quite sure it will be run under python3, so it's generally a good idea, IMHO.

If there really are shebangs or calls to python instead of python3, but the targets are compatible, then the distributions can patch those to python3 as needed without much trouble anyway, so, for now, we can consider this issue over. Later, in a few years, once the situation on the interpreter name stabilizes, this choice can be reviewed.

I see... so some distros basically want to push towards Python 3 but are too afraid to do it "properly" by also switching the target of "python". ;-)

I'd be totally fine with replacing "python" with "python3" on the Inkscape-side if we targeted python3 only.

However the idea for Inkscape (at least the "LTS" branch 0.92.x) is to support both, python2 and python3, and we can't offer that level of compatibility by forcing calls to python3.

So yes, I think patching on your side is the way to go for now. If you should find any scripts that are *not* compatible with python3 let us know.

> However the idea for Inkscape (at least the "LTS" branch 0.92.x) is to support both, python2 and python3,

I'm wondering if this might be a mistake. After all, Python 2 will be unsupported by upstream in a few months time. Not even security bugs will be fixed, so using it is dangerous from then on. By providing support for Python 2, you're basically asserting to the Inkscape user that everything is fine and she can keep going, but that isn't the case. Everybody should feel a great deal of pressure for upgrading now! That's why many projects have pledged to remove Python 2 support before the end of the year [1]. I maintain a bunch of more or less popular Python projects, and have purposefully removed Python 2 support from all of them. That itches some users but, again, I think this is a good thing. The more people a pressured into upgrading, the better.

[1] https://python3statement.org/

I'm working on communications regarding the sunsetting of Python 2.x [0] The way I understand & have phrased my understanding[1] of Inkscape's plans is: Inkscape's LTS 0.92.x line aims to continue supporting Python 2.7 but Inkscape 0.92.5 will also support Python 3, and the 1.0 line will drop support for Python 2. And, as I understand it, Inkscape hopes to release 0.92.5 and 1.0 this calendar year, but that's a hope, not a firm commitment.

[0] https://www.python.org/doc/sunset-python-2/

[1] http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#when-can-we-expect-python-2-to-be-a-purely-historical-relic

As far as I know, Inkscape 1.0 has not dropped support for Python 2.7, but aims to keep supporting old third-party extensions, so users can still use them, even if their maintainer hasn't updated them yet.

So I guess you'll need to update your article. There is nothing about that in the linked release notes draft.

Yes, we still support Python 2, although the preference is to use Python 3 together with Inkscape 1.0.

For example Mac and Windows packages ship with Python 3, so extensions not compatible with Python 3 won't run out-of-the-box.

Everything shipped with Inkscape is supposed to run with both Python 2 and Python3, though.

So it seems that in the current 1.0 beta1, there are 6 calls to `python` in the various CMakeLists.txt that I had to patch to use python3.

Maybe you could add a cmake option to let the user select the python binary?

Doesn't the OS define what 'python' refers to?
Are there many other programs that still need Python2 and don't label it as such?

(this doesn't mean that there shouldn't be such a switch, I'm just curious why this needs to be patched at all when the alias could just be changed and then the whole system would switch).

Yes the OS defines it, but first within Debian we still have quite a few
packages calling "python" and expecting python2, we are still chasing them
down.

Then, clearly we can never know of however many users scripts and whatnot
that require py2.

So we have decided long ago to just make the /usr/bin/python symlink
disappear: that simply removes a whole lot of uncertainties.

On Sat, 28 Sep 2019, 2:10 pm Hachmann, <email address hidden> wrote:

> Doesn't the OS define what 'python' refers to?
> Are there many other programs that still need Python2 and don't label it
> as such?
>
> (this doesn't mean that there shouldn't be such a switch, I'm just
> curious why this needs to be patched at all when the alias could just be
> changed and then the whole system would switch).
>
> --
> You received this bug notification because you are subscribed to
> inkscape in Ubuntu.
> https://bugs.launchpad.net/bugs/1735363
>
> Title:
> inkscape: Port to Python 3
>
> Status in Inkscape:
> Fix Committed
> Status in inkscape package in Ubuntu:
> Confirmed
> Status in inkscape package in Debian:
> Confirmed
> Status in inkscape package in Fedora:
> Invalid
>
> Bug description:
> inkscape: Use/Port of Python3 needed, or considering demotion.
>
> Currently seeded in usb (???), owned by desktop-packages.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/inkscape/+bug/1735363/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=inkscape; milestone=0.92.5; status=Fix Committed;
> importance=Medium; assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=inkscape;
> component=universe; status=Confirmed; importance=Wishlist; assignee=None;
> Launchpad-Bug: distribution=debian; sourcepackage=inkscape;
> component=main; status=Confirmed; importance=Unknown; assignee=None;
> Launchpad-Bug: distribution=fedora; sourcepackage=inkscape;
> component=None; status=Invalid; importance=Undecided; assignee=None;
> Launchpad-Bug-Tags: py2-removal
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: bryce doko ede123 gwync-redhat-bugs janitor
> jbicha junghans junghans-redhat-bugs mapreri marenhachmann
> mattia.verga-redhat-bugs nschloe stefan-bruens sumanah ted valavanisalex
> Launchpad-Bug-Reporter: Matthias Klose (doko)
> Launchpad-Bug-Modifier: Hachmann (marenhachmann)
> Launchpad-Message-Rationale: Subscriber (inkscape in Ubuntu)
> Launchpad-Message-For: mapreri
>

Ah, thank you for explaining, Mattia!

I think Patrick (ede123) will read this here, but if he doesn't reply, please ping people in IRC.

> Maybe you could add a cmake option to let the user
> select the python binary?

That sounds like a reasonable approach, however I wonder:
* Would you expect the shebang to be adjusted for python3 as well
  (which would require us to configure .py files as a build step
  in this case and seems like a lot of likely unneccessary hassle),
  or would it be fine to call "${python} script.py" from within
  cmake and ignore the shebang?
* I suspect we should also make the binary name that is
  hardcoded into the inkscape binary configurable in this case?
  While possible, I'm a bit afraid it might be unflexible or even
  unpredictable for users:
  Nowadays, they just expect Inkscape to call "python" (so they
  can predict which version of python Inkscape will use by running
  "python --version" from the command line).
  Now we would hardcode any of "python", "python2" or "python3"
  as "default interpreter" with no immediately obvious way for
  users to know which it is.
  Are we sure this would not cause problems in the long run?
  On Windows for example official CPython packages even use
  "python.exe" no matter whether it's Python2 or Python3, so
  at least on this platform I probably wouldn't want to make
  the default call anything else (even if I could make sure the
  bundled Python is called "python3").

> So we have decided long ago to just make the /usr/bin/python symlink
> disappear: that simply removes a whole lot of uncertainties.

Out of curiosity: Is this documented somewhere?
Making packages to call an explicit version because "python" is going to be removed sounds a lot more sane than making packages call "python3" while keeping "python" as an implicit fallback to "python2".
Then again from a general point of view the question is whether it really makes sense to treat Python differently from most other versioned software and hardcode a version number into the executable name to start with. (Nobody would consider directly calling "python3.x", because it would just not be practical either, while 3.x versions are not always API compatible either)

> * Would you expect the shebang to be adjusted for python3 as well

Not really. You are already calling `python path/to/script.py` right now; that already ignores the shebang, and so I don't really care of changing that right now. Since it's used only a build time, I care even less.

> * I suspect we should also make the binary name that is
> hardcoded into the inkscape binary configurable in this case?

Honestly, the situation is currently way too messy especially across multiple platforms and Linux distributions, as I said. IMHO, the probably best solution is for you to not rely on anything, and detect the best interpreter at run time (here, perhaps due to my involvement in Debian, I suggest preferring `python3`.

BTW, so how are the plugins invoked in 1.0? In the past inkscape even linked against libpython, but now it's not anymore. Is it forking out an external python process directly? (that means I should be adding a manual hard dependency on the python interpreter to the Debian package, as otherwise it wouldn't get any…)

> Out of curiosity: Is this documented somewhere?

I'm sure it is somewhere, but I wouldn't know. Most of my knowledge comes from following the matters across multiple mailing lists and other media…

I think that, apart from the build process, there is only this bit that would need to be chnaged. So I'm currently doing this, but I'd love to be able to specify that at build time (or for inkscape to detect it by itself, as I suggested above):

--- a/src/extension/implementation/script.cpp
+++ b/src/extension/implementation/script.cpp
@@ -77,7 +77,7 @@
         {"python", "python-interpreter", "pythonw" },
 #else
         {"perl", "perl-interpreter", "perl" },
- {"python", "python-interpreter", "python" },
+ {"python", "python-interpreter", "python3" },
 #endif
         {"ruby", "ruby-interpreter", "ruby" },
         {"shell", "shell-interpreter", "sh" },

fixed in latest groovy package:
https://launchpad.net/ubuntu/+source/inkscape/1.0~rc1-3

Will Inkscape version 1.0 with this fix also go into updates or backports for Focal?

This Ubuntu release should not depend on Python 2 https://www.fosslinux.com/26413/ubuntu-20-04-lts-focal-fossa-set-to-remove-python-2.htm so in terms of LTS, that would be very desirable.

I've recently installed Ubuntu 20.04 and Inkscape on it. Turns out number of effects from Extensions menu does not work. I can only see a dialog box for a split second and nothing happens. I believe this bug is the problem. So what are the options for the latest Ubuntu LTS users?

Now I've installed the stable version from snapcraft. The effects seems to work but the interface looks like old Windows :/

@mpredotka please file what you are seeing (with as many details as possible) in a different bug, this is totally unrelated.

@pander

It's very unlikely Inkscape 1.0 will ever go into -updates.
1.0 changed many things, including the command line options, that *do* break other packages (just two days ago, a fellow Debian Developer wrote to me about this). Unfortunately, Inkscape 1.0 came too late to be included in Ubuntu 20.04.

The Ubuntu backports project is basically dead, and has been so for years. If anybody ever revive it I'll gladly upload Inkscape there, but don't hope too much. It's easier to just use the PPA.

Lastly, it's not true that "This Ubuntu release should not depend on Python 2". Python 2 has not been removed, what has been removed is the unversioned /usr/bin/python binary, but `python2` is still there. We went a long way trying to remove python2, but there are still too many packages depending on it that we didn't make it in time.

Thanks for the extra information. I will use the PPA.

Which PPA offers Inkscape 1.0 build for Focal?

It's going to be the stable one, when the issues with the build failures (due to tests ...) are fixed. No ETA, hopefully within the next couple days.

it's now available in https://launchpad.net/~inkscape.dev/+archive/ubuntu/stable?field.series_filter=focal