m.grl
m.grl copied to clipboard
Aeva
blender plugin needs documentation, better distribution method
To make this really easy(?), we should bundle numpy rather than require the user install it, so that we can distribute the blender plugin as a zip file and link to an existing tutorial that explains how to install it.
I agree that bundling is bad practice, but not doing this is very unfriendly to users. Debian doesn't accept bundled libraries either, and it has a simple solution: it doesn't use them. AFAIK Fedora does the same. So upstream (that's this project) can bundle things like Numpy for convenience, and Debian and Fedora ignore the bundled library and use their packaged version of the software instead.
I haven't looked at packaging yet, but Numpy is not a problem, because it is packaged. I have seen that the matrix library is not (at least in Debian), so that needs to be done. But that's our problem as packagers; I don't think it's reasonable to request upstreams to drop bundled libraries from their releases just because we have a better solution. Because that solution (automated dependency handling) doesn't work outside of distributions. Upstream releases are used by distributions to make packages, but that's not what their primary target is.
oh! I did some research on this recently, but didn't update the ticket - Blender actually bundles numpy in everything except the builds packaged for gnu distributions. So, providing a zip file of the plugin for non-gnu users to use + a note for those that do but chose to install the plugin manually will also need to make sure numpy is present on their system.
At whatever point the plugin is packaged for distribution, I agree, it is best to let numpy be a dependency.
As for the javascript side of things; I have no idea what situation would be useful for there to be a .deb file for mgrl.js, given that there is neither a meaningful convention for distributing js libraries like this (neither of these are nope.js libs - they are both intended to be pushed over http to be used and associated to specific highly configurable paths), nor is there a use case I can think of where it would be useful. At any rate, the javascript side is out of the scope of this ticket, as the blender plugin does not make use of them at all.
Ah, that's nice.
There's been a pretty long discussion on Debian's lists about javascript preprocessors; we want source for them and AIUI that is a problem because everyone ships their own version with their project, so there are almost as many versions of the source as there are projects that use them, which is a support nightmare, especially from a security standpoint. So if what you're using has an upstream release, please use it unmodified so Debian and other packagers can use upstream's version instead for building.
As for javascript libraries like m.grl, I think it makes a lot of sense to package them. For example, jquery is also packaged. The recommended method for packaging a jquery program in Debian is by ignoring the bundled jquery from upstream and instead adding a symlink to the file from jquery's package into the place where your own package's html is served from. That way there is only one version of jquery in Debian to maintain. If (when) I'll package games that use m.grl, I'm planning to do exactly the same for it.