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