Thanks to Tav's for his excellent hackfest overview which related
general annoyance about extensions, it pointed to Uniconvertor being a
I'm sorry I wasn't at the meeting to talk about the issues around
packaging extensions more directly. So I'm hoping this email can fill
in for that and get some of the information I would have conveyed at
I won't speak to the API breaking, since Thomas and others have done
very good work making sure that the API has greater backwards
compatibility and is much less likely to break in older code. (now)
But the specific issue here is about how we ship different extensions.
There has historically been a fixed relationship between the
`share/extensions` directory and what we ship. When we moved the
extensions into their own repository, we included the git as a sub
module to continue this relationship.
But as development has progressed, it's become clear that there's way
too much variability to both have a solid extensions project and keep
this fixed one to one relationship.
Take Uniconvertor as an example. It's a bunch of extensions that call
software which must already be installed to work. Which are both
important to Inkscape and impossible to corral into a standard code
quality framework. They've been moved to so they can be developed
separately to provide them with more latitude.
Now this breaks the build time assumptions about what is in the
share/extensions directory at dev time. Because now we have a situation
where packagers are not guaranteed to have all the extensions they may
want to ship. But this must be so, because while the core extensions
should provide a stable API, the doc callers for the help menu and
basic extensions; other extensions are often not written in python,
have no tests, don't have code quality checks, use external programs
which may not be installed and are even only used on windows (but we
ship them to linux users currently).
The future of extensions will be the extension-manager which will
allow inkscape users to install extra functionality without
requiring Inkscape to ship quite so many extensions by default. You can
see Uniconvertor extensions packaged on test pypi here for a flavour of
what this would look like. (The plan for 1.0 is to ship the manager
as a stand alone app that can be installed separately for testing)
But before that glorious future; all Inkscape packagers need to be able
to bundle in extensions different locations so that they can package in
all the things their users will need. This should provide them with far
more power to decide what's important than currently, where extensions
are denied from installers because of developer reasons.
I do not know how packagers wish to do this. Linux packagers may want
to link to uniconvertor as a recommends package with it's own
dependencies (which would be good). Windows and Mac may want to
literally include the code into their distribution. (I'm hoping this
email can spark a discussion so we can get the tooling right for all
So far I feel that I've ruffled feathers by removing extensions. But I
don't believe that the build time extensions are the same thing as the
developer time core extensions and I hope this email goes some way to
laying out the logic for this and why it would make the Inkscape
project stronger to do it this way.
On Sat, Jun 08, 2019 at 08:53:59AM -0400, [hidden email] wrote:
> I do not know how packagers wish to do this. Linux packagers may want
> to link to uniconvertor as a recommends package with it's own
> dependencies (which would be good).
I'd happily do so in Debian/Ubuntu, if it wasn't that uniconvertor is
horribly broken there (mostly my fault, meh). Reason in our case is
that it has no maintainer, and it now requires the unpackaged sk1libs.
So it "just" needs somebody caring about it.