Am 05.02.2018 um 18:08 schrieb Ted Gould:
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.
- That 'one package for all (that depend on numpy)' was what I meant, (but didn't want, tbh.). Thank you for all those explanations!
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.
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?
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.
Maren
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