Dear developers,

Thanks to Tav's for his excellent hackfest overview which related general annoyance about extensions, it pointed to Uniconvertor being a particular issue.

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

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[1] 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[2] which will allow inkscape users to install extra functionality[3] 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[4]. (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 packager types).

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.

Best Regards, Martin Owens

1. https://gitlab.com/inkscape/extras/extensions-uniconvertor 2. https://gitlab.com/inkscape/extension-manager 3. https://twitter.com/realdoctormo/status/1134107821249847298 4. https://test.pypi.org/project/inkscape-uniconvertor/