INKSCAPE Installed isn't opening

Ubuntu
35

I’m late to this party, but… a lot of problems with Inkscape 1.x are caused by extensions — specifically, Python extensions. (Not necessarily user-installed / add-on extensions — the Inkscape distribution comes with a lot of functionality that’s implemented as preinstalled Python extensions). You can’t really run Inkscape without Python anymore, and therein can lie the problem.

Python is good at a lot of things, but there are also some things it doesn’t handle well at all.

  1. It isn’t very good at dependency management.

    I suspect @JANDOE 's message in the OP:

    “Extension “Export to PDF via Scribus” failed to load because a dependency was not met.”

    …was likely caused by a missing Python package in Inkscape’s Python install. Which package? No idea! Seems like it should tell us, doesn’t it?

    Well… remember how I said the dependency management is shitty? Let’s just label that message Exhibit A.

  2. It really isn’t good at backwards-compatibility in the core language. Python 3.10 broke the entire world with one tiny change: it no longer accepted passing floating-point values to integer function-call parameters.

    In Python 3.9, 3.8. 3.7, … if you had a function that took two integer parameters, say gridPoint(x, y) where x and y are both integers, you could call gridPoint(3, 2.5) with no problems. Python would just happily truncate the value 2.5 to 2 and go on its merry way.

    Starting with Python 3.10, that call triggers a traceback rather than narrowing the 2.5 value and losing precision. A huge amount of pre-Python 3.10 code out in the wild contains implicit narrowing bugs, as was only discovered when the tracebacks started flying the first time it was run under Python 3.10+. The only solution to making it work under Python 3.10 is to update the code.

    Technically this change wasn’t “sudden” (it only felt that way), because for several Python versions prior to 3.10, deprecation warnings would be triggered by instances of implicit narrowing, noting that as of Python 3.10 the warnings would instead become errors. So, in theory it was possible to detect and fix these issues by running affected code under Python 3.8 or Python 3.9.

    …In theory. In reality, the problem is that those deprecation warnings ARE DISABLED BY DEFAULT.1 So, unless a developer was proactive enough to go looking for them,2 there wouldn’t have been any indication that their code contains errors that would cause it to crash under Python 3.10+.

    The implicit-narrowing thing is just one example, the most recent and spectacular, but there have been plenty of other backwards-incompatible changes along those lines; there are some in practically every minor version release of the Python core.

    Python isn’t quite Lua. (Lua 5.1, 5.2, 5.3, 5.4, etc… are all completely separate, incompatible languages, and code written for any specific version is expected to require modifications before it will run on any of the others.) But it suffers from a lesser version of the same thing, just without having the balls to be honest about it.

For a scenario where user-installed code from various sources may be run, not all of it necessarily kept up to date, these things all add up to a pretty fragile environment unfortunately.

Snap/Flatpak packages tend to work better, at least for the bundled extensions, because the Python version in use is typically controlled rather than being at the whim of the system installation. (On Fedora, in particular, that’s usually the latest and greatest release, a version much of the bundled code may not have been tested against, and may not run properly under (see above.)

But those packaged builds also make it harder to work with user-installed extensions, since they tend to be sandboxed, self-contained, and not very easily extensible.

I don’t have any great solutions to offer, it’s all kind of a mess. And that’s just on the Python front. There may be other types of issues besides those, as others have pointed out.

Notes

  1. Why? FuckIfIKnow. Because the Python language developers enjoy watching people fall through trap doors? Because they hate the sight of running code? I can’t come up with any non-stupid reasons, so we can assume that whatever reasons they have are pretty damn stupid.

  2. Anyone who writes, maintains, or even just runs Python code should try running it in a terminal with PYTHONWARNINGS=always set in the process environment. Just watch the warnings fly!

3 Likes