Le 21/01/2017 à 11:50, katja a écrit :
Liam,

Choosing a unique name for an external is indeed the best warranty to avoid 
conflicts. Not only a future release of a dependency has the potential to break 
your patch. An old release with a bug or missing feature can do that too! It 
seems there's no way to force Pd loading the executable that sits in your 
project tree (I would be very happy if someone can prove me wrong).

you can put binary and abstraction in a directory with unique name.
if you want to use a [counter] object, you can put it :
project_folder/unique_directory_name/counter

for patch that are located in the project_folder, you can load 
[unique_directory_name/counter].
this way your can be sure that you will not load any "counter" that came with 
any other lib.





For "egregore source", we choose to start a script with "pd -noprefs", and 
declare only the mandatory path (that are in our project tree), so that user configuration did not 
mess our patch.



cyrille



So if you're concerned about versions of externals breaking your patch, you 
could preventively fork them under a different and very specific name. Like 
'contxt_demux', 'contxt_initbang'. I won't advise against it because the issue 
of name clash in pd is serious enough to consider all strategies, but be aware 
that forking is a bit more involved than simply renaming an existing binary 
(which won't do the trick as IOhannes has already mentioned).

In either case (modified class names or not) a redistribution of GPL licensed 
software should include the sources, and when you redistribute a subset you 
need a customized build system.

Note that I'm not advertising to redistribute, just detailing the consequences. 
I learn from this discussion too.

Katja



On Fri, Jan 20, 2017 at 5:22 PM, Liam Goodacre <liamg...@hotmail.com 
<mailto:liamg...@hotmail.com>> wrote:

    Dear all:


    Thanks for the detailed responses. My main interest here is, as Katja mentioned, the 
desire for a one-click-buy option (minus the "buy"). A secondary concern is 
that some future release of an external will change somehow break the patch, although 
this doesn't seem likely, given how slowly externals tend to move and the general 
commitment to backwards compatibility.


    I like Fred's idea of distributing two packages, one with- and one without externals*. However, I 
take Katja's point seriously that forcing two versions of the same file on the same disk could become 
problematic. A quick and dirty solution to this might be to rename all the external files that are 
uploaded in the Context deken package (ie. "demux.pd_linux" --> 
"demux2.pd_linux"). This would solve the problem as far as I can see, although it seems 
somehow wrong. What are people's thoughts about this?


    Two other points that are worth mentioning:


    1. Context depends on [initbang] from iemguts 0.2.1. Last time I checked, 
the deken package for this was only available for Windows, not Linux or Mac.


    2. I haven't used the [declare] object at all, given the warning in the 
help file against using it in abstractions. Instead, each external is declared 
in the object name.




    *Actually, four versions: one for Windows, Linux Mac, and one without 
externals.


    Liam

    
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    *From:* katja <katjavet...@gmail.com <mailto:katjavet...@gmail.com>>
    *Sent:* 20 January 2017 15:29
    *To:* Liam Goodacre
    *Cc:* PD list
    *Subject:* Re: [PD] repackaging externals on Deken

    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...@hotmail.com 
<mailto:liamg...@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 <mailto:Pd-list@lists.iem.at> mailing list
    > UNSUBSCRIBE and account-management ->
    > https://lists.puredata.info/listinfo/pd-list 
<https://lists.puredata.info/listinfo/pd-list>
    Pd-list Info Page <https://lists.puredata.info/listinfo/pd-list>
    lists.puredata.info <http://lists.puredata.info>
    Pd (standing for Pure Data) is a Max-like graphical realtime-computermusic 
language, written by Miller S. Puckette (et al.) This mailinglist is meant as a 
platform ...


    >

    _______________________________________________
    Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
    UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list 
<https://lists.puredata.info/listinfo/pd-list>




_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to