Am 04.02.2018 um 18:37 schrieb Marc Jeanmougin:

...

Or could numpy be made a dependency? (I guess that's more a question to packagers - do we make any recommendations anywhere? Or do they need to figure it all out by themselves?)

Mmh, python-numpy is already in "Recommends:" of the packaging for debian and ubuntu, and is hence installed by default (when installing with apt)

- Yes, for Ubuntu. The user was using recent Mint. And python-numpy wasn't installed.

I just found out this is a peculiarity of Linux Mint - it does not install recommended packages, but explicity sets that setting to 'false' in its apt config.

So I guess adding that warning in, like for the other extensions, would be the preferred way to go? Or would it make sense to move numpy from 'recommends' to 'required'?

Maren

---

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

Maybe the proper packaging way would be to have a separate package inkscape-extension-gcodetools that depends on python-numpy

On 02/04/2018 06:57 PM, maren via Inkscape-devel wrote:

...

So I guess adding that warning in, like for the other extensions, would be the preferred way to go? Or would it make sense to move numpy from 'recommends' to 'required'?

On Sun, Feb 04, 2018 at 07:16:14PM +0100, Maren Hachmann wrote:

Then we would need to do the same for all the other extensions that use numpy, too. There are lots of those.

I know there has been talk about separating extensions out into their own packages - but I got the impression that's more or less a long term solution, for which we lack volunteers... and not a solution that will help with 0.92.3, or probably even 0.93.

(or would anyone be interested in separating extensions out?)

Would a short term fix via error message be okay, until something like that happens?

If people thinks moving a bunch of /usr/share/inkscape/extensions/foo.py files in its own binary package (say, inkscape-extensions-blah), that's trivial to do, and I could do it even now, but would it really help?

Then that package would a recommendency itself, so people installing 'inkscape' on a Mint box wouldn't get the extension and then complain again about that as well.

IMHO, having the extension catch the failed numpy import and gracefully error out saying "to use this thing you need to install the python(3?) numpy module" is a very fine final solution.

On 02/04/2018 12:16 PM, Maren Hachmann wrote:

Then we would need to do the same for all the other extensions that use numpy, too. There are lots of those.

Generally with Deb's you want to try to not have a ton of small packages. The small packages make the indexes larger, which is what everyone has to download every night. It is one of the reasons you could never scale a Debian archive to something like the millions of applications in the Play or App store.

One package for all the Python extensions, Ruby, etc. might make more sense. That work would have to be done in Debian, and then sync'd in to Ubuntu. It is pretty late to make the LTS at this point. (and packaging changes like that are rarely approved for backport)  You'd really be targetting the 20.04 LTS for most users at this point.

I know there has been talk about separating extensions out into their own packages - but I got the impression that's more or less a long term solution, for which we lack volunteers... and not a solution that will help with 0.92.3, or probably even 0.93.

(or would anyone be interested in separating extensions out?)

This is my goal long term for the snap. The problem is that the snap format doesn't have everything we need to do this today. I've been requesting the features we need.

For me, there are two reasons to do this. One so that we can make snap not have to include everything for every extension. The second is so that extension developers can upload and manage their own extensions. And, if they choose, charge money for them.

Would a short term fix via error message be okay, until something like that happens?

The extensions have a dependency checking mechanism already, where in it can look for binaries. That could probably be extended to look for Python modules as well. I'm not sure how one writes C code to look for a Python module, but I think that's probably the long term answer. Then we can hide those that won't work like we do for when binaries are missing.

Ted

On 02/05/2018 11:52 AM, Maren Hachmann wrote:

...

...

I know there has been talk about separating extensions out into their own packages - but I got the impression that's more or less a long term solution, for which we lack volunteers... and not a solution that will help with 0.92.3, or probably even 0.93.

(or would anyone be interested in separating extensions out?)

This is my goal long term for the snap. The problem is that the snap format doesn't have everything we need to do this today. I've been requesting the features we need.

• There was talk about having them in a separate git repository,

comparable to ... atom editor plugins, or pelican website generator plugins, for example, and having them managed by a different set of developers. That was what I meant here. Sorry, I've been a bit vague.

Sorry, yes, I think that'd be good too. Somewhat orthogonal though as they could be a separate repository and still in the main Inkscape package. Also vice-versa. I imagine that for anything we have as a download (i.e. a Windows installer) we'll want to include a bunch of extensions. The only place that I can imagine separating them being useful is distributing through stores that have a prompt for other downloadable content.

...

For me, there are two reasons to do this. One so that we can make snap not have to include everything for every extension. The second is so that extension developers can upload and manage their own extensions. And, if they choose, charge money for them.

• They already can do that now, I think? At least I've seen separate deb

packages for extensions. I suspect it's not currently possible with snap to save stuff in the directories of another snap (i.e. move the extensions into Inkscape's extensions directory), is that what you mean?

Snaps can actually share directories, the problem is executing the extension. There's no way currently for a snap to execute another snap. For debs there's no real security besides file permissions, so things work fine there.

I would argue that extension developers could make debs, but they can't easily distribute them. Getting into the trusted Debian archives for their OS is difficult, and not practical. Things like PPAs are such a large security risk I don't consider them a practical solution. They're fine for groups of folks working together who trust each other, but they require an impractical amount of trust in every uploader to that PPA for them to be useful for general users.

...

...

Would a short term fix via error message be okay, until something like that happens?

The extensions have a dependency checking mechanism already, where in it can look for binaries. That could probably be extended to look for Python modules as well. I'm not sure how one writes C code to look for a Python module, but I think that's probably the long term answer. Then we can hide those that won't work like we do for when binaries are missing.

• I find that hiding already is problematic, it's not helping people

find the things they need. I often see people wonder why they don't have extension xyz, which they have seen in some video.

It would make more sense if there were an automatic message at the very first start of Inkscape, or some 'module' overview, as there is for other programs. There it tells you 'If you want optional functionality x to work, you need to have abc. Get abc ->'.

People will look for hidden gcodetools on the web (although they already have a compatible version), and go and install them from somewhere else, and wonder why they still don't work. They do *not* usually look into the extension-errors.log. Most don't even know where their preferences file is, or where to put new extensions, let alone are able to dig into error logs to find out what is going wrong. (Those who *do* look in there are usually worried that important things are missing, because they don't really understand it).

Hiding is fine (for me) if a user *knows* that it's hidden, and is okay with it, because he/she doesn't need it. Hiding without informing people about what's happening is not nice, in my opinion.

Please don't hide the gcodetools :-( - I'd like to just add the error message (no new strings, promise!)

I wouldn't mind making extensions optional (even though I find that many of them supply something that could be considered core functionality), or what I'd like even better would be to have some functionality inside Inkscape that lets you choose which ones you want to install, and to have a kind of 'shop' for them. But currently I'm a bit worried about the security implications that would have, and about the amount of maintenance work that it would require. It's more of a dream, I guess, but one that came up in various discussions.

Yes, I don't think us implementing an App store makes sense. That's the domain of OS vendors, and they've all done it already for us. They provide means for doing DLC for their OS, we should use those mechanisms. But, I think it makes sense to integrate with the means they had in a way that provides a positive experience.

I understand your concern with hiding functionality. The problem becomes: "I know I don't have numpy, stop filling up my menus with stuff I can't use." I'd agree that we need to provide a way to discover why things aren't starting up as expected better, and a hidden file isn't a great solution. I worry about going down the route of providing installation instructions because of the complexity of how everything is configured (a config option of Mint is what started this discussion!). And also things like "install numpy" is super technical. I don't want to say there is no solution, just point out some of the landmines on the path. We can do better, but I don't think we can entirely work around every distributor's choice without reinventing packaging.

Ted