numpy: include, give warning or ...?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

numpy: include, give warning or ...?

Maren Hachmann
Hi there,

the .deb packages for Ubuntu do not seem to include a dependency for
numpy, but the gcodetools depend on it.

It's included in the snap, and also seems to be present for Windows and
macOS versions.

Some other extensions give warnings when it's missing (measure,
perspective, dxf_outline,...)

So, my question is:

Should the gcodetools also just output a warning message with install
instructions, like the other extensions do, because there's a reason why
numpy cannot be made a dependency?

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?)

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

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)

--
Mc


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

Maren Hachmann
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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

Inkscape - Dev mailing list
Am 04.02.2018 um 18:50 schrieb Maren Hachmann:

> 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'?
- Probably not a good idea with the requires, because of pip?

Maren

> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

Marc Jeanmougin
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'?


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

Maren Hachmann
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?

Maren

Am 04.02.2018 um 19:05 schrieb Marc Jeanmougin:

> 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'?
>
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

Mattia Rizzolo
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.

--
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

Maximilian Gaukler
In reply to this post by Maren Hachmann
If Linux Mint chooses not to install recommended dependencies
(seriously?), it's their decision and therefore their problem. Someone
using Linux Mint should report it as a bug with them.

To quote the documentation of the Debian package format which is also
used by Mint:
 > The Recommends field should list packages that would be found
together with this [package] in all but unusual installations.
https://www.debian.org/doc/debian-policy/#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

Moving it to "Depends" would be wrong, as inkscape still mostly works
without numpy:
 > ["Depends"] declares an absolute dependency.

Of course, printing a sensible warning for missing python packages is
always a good idea.


Regards,

Max

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

Ted Gould
In reply to this post by Maren Hachmann
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

Maren Hachmann
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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: numpy: include, give warning or ...?

Ted Gould
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel