In the early days of Raspberry Pi I has a need to redistribute a few externals with PicoJockey, an ARMv6 targeted version of SliceJockey, because Pd-extended did not explicitly support the platform. PicoJockey includes a source tree with subsets of some external libraries plus a custom build system, and a binary build for ARMv6.
This was in the pre-deken era, and while it would be technically possible to distribute PicoJockey (or any Pd project) in such a format via deken, I seriously doubt whether that it is a good idea. Libraries in deken are versioned, and so would be a project that depends on libraries. A project can only specify it's own version in the deken interface. Now imagine a project silently installs unspecified versions of other packages, or subsets thereof? Even when they reside in a subtree of the project, they will conflict with 'official' versions if not identical. This can be a source of confusion and frustration no matter how well you know Pd.
I perfectly understand your desire for a 'one click buy', Liam. That's what I wanted for SliceJockey and PicoJockey as well. It's good for your project and also for the reputation of Pd when things work out of the box. But we have to recognize the fragility of a dependency chain. Even in the heyday of Pd-extended a library update could wreck your 'one click' project and leave people puzzled why it stopped working. In my experience, a Pd project with 'app convenience' is an illusion that can hold for only a while. When a project suggests to be self-containing, users are unaware of dependencies and clueless if something breaks.
Externals are plugins no matter how they are distributed. Be sure to accurately and conspiciously document all dependencies of your project, on your project page and in the distribution. Then if something breaks, people will hopefully remember to check dependencies and come back to your project page for info or updates. Some dependencies are more susceptible to break than others (e.g. unmaintained / orphaned / complicated / debated / forked libs).
You could use various distribution methods according to target audience and release cycle. Why not start with an alpha test release for vanilla + deken? If your project provides clear dependency statements and include mechanisms like [declare] objects, your alpha testers should be settled with a few deken clicks instead of just one. If not... oh yeah... now I remember your problem with one external not being up to date in deken. Is that a consideration for 'repackaging'?
Katja
On Wed, Jan 18, 2017 at 5:12 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
Hi all
I'm starting to think about how to distribute the Context sequencer when it is ready (hopefully the day is not very far away). Context is an abstraction, but it relies heavily on externals*. Ideally, I want it up on Deken, but I'm not sure what to do about the external packages. Is it feasible / acceptable to bundle all the externals I'm using into a folder and distribute them along with the main Context package? I'm hoping that this way the whole thing could be downloaded and installed in one click, but I want to make sure that there aren't any complications or license issues. Has external repackaging been done before?
*The external libraries I'm using are:
-cyclone
-zexy
-iemguts (including initbang)
-moocow
-flatgui
-list-abs
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list