It's good to see progress starting on this. The roadmap lists this as a task for 0.93, and this is a good point in the release process to start hacking on it.
As Ted and Eduard point out, the task may sound simpler than it really is. This might be one of those types of things where the hard part is coming up with a plan of attack. It's good that some actual work has been done so there's something to focus critique on. I do agree we need to find consensus on an approach before moving from experimentation to integration of the change into the main codebase.
I'd like to see some additional thought into how this is hosted in gitlab. I.e. it may make sense to establish a subteam that owns the extensions, so that for example contributor permissions can be managed differently than we'd want for the core codebase. I don't really have a solid idea in mind here, but perhaps we can brainstorm a bit next week?
As an old school Linux packager, the proposed approach feels natural to me, but Ted and Eduard make good points that it may not be as clean a fit on other platforms that Inkscape needs to be on. It may be worth doing some analysis into how similar software projects solve this problem. It's entirely possible there is no perfect solution that would address everyone's desires - but I'm hopeful we can at least find an approach that is at least workable.
One difficulty here is that if we provide a distribution/installation system for 3rd party extension writers to use, then if we change that system they'll be quite grumpy. Yet getting all the requirements satisfied in one go would be a formiddable challenge.
It may benefit us to do this in a few stages. For instance, a first step might have the extensions housed in their own gitlab repository and subteam, but still be integrated into the source tarball at release time, thus sidestepping all of the packaging/platform problems but gaining some of the team membership flexibility. A next step would focus on modularizing the extension installation, but keeping distribution centralized as we do it now (i.e. everything is released in concert with the main release). A later step would work on modularizing distribution to work asynchronously, so users can install and update modules at will.
Let's definitely plan on talking about extensions and modularization in general at the hackfest.
Bryce
On Thu, Mar 22, 2018 at 12:15:42AM -0500, Ted Gould wrote:
On 03/21/2018 10:54 PM, Martin Owens wrote:
Firstly we put any non-python extensions into their own repository. We don't want to drop support for just running weird shell scripts and perl stuff, but I'd put it in auxiliary and ask packagers to add them to separate packages.
Frankly, you're thinking like old school Linux packaging. Multiple packages with dependencies isn't really how most modern OSes are thinking right now. So I think that relying on that is perhaps a play towards the past.
I'd agree on the goals of making it so that an extension can be published separately, on a separate schedule, and work well in Inkscape. But, I don't think we're to the point of that working well with things like dropping to command line instructions, much less being user friendly enough to be practical.
This is so we can focus the core extensions repository on making it a python installable module set with the inx coming along as data.
The reason we'd want to move in this direction is really to allow inkscape to install and uninstall extensions while not having to write our own dependency software.
If we take advantage of pip/virtualenv in our .local/share/inkscape/extensions (Or do we stuff everything in .config like naughty XDG users 😉) then we can install extensions from zi p files, from git repositories on github and do uninstalls by just managing the pip repository from the inkscape UI.
This will install all the required dependencies (numpy anyone?) and keep files separated.
Installing executables in your home directory is a security nightmare. We really don't want to be in that business. And I have doubts that'll work in Windows, but there may be some magic there I don't know about. PIP does some fun things with compiling executables and libraries when it needs them.
I hate to be stop energy on porting the python extensions to Python 3, that clearly needs to happen. But I don't think we're ready to have them shipping and developed out of a different repository. The distribution issues are critical there. I think that we need a test extension that works well in all the repos/stores/etc before we can split out the extensions that we have.
Ted
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel