Re: [PD] repackaging externals on Deken

2017-01-24 Thread katja
kages in their own right. Katja > > > From: katja <katjavet...@gmail.com> > Sent: 21 January 2017 10:50 > > To: Liam Goodacre > Cc: PD list > Subject: Re: [PD] repackaging externals on Deken > > Liam, > > Choosing a unique name for an ext

Re: [PD] repackaging externals on Deken

2017-01-23 Thread katja
On Mon, Jan 23, 2017 at 1:04 PM, IOhannes m zmoelnig wrote: > On 2017-01-21 11:50, katja wrote: >> 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

Re: [PD] repackaging externals on Deken

2017-01-23 Thread IOhannes m zmoelnig
On 2017-01-23 05:00, Liam Goodacre wrote: > What would be involved in forking an external I don't think there is any good fool-proof, one-click solution. but i do think that forking the source code for the sake of distributing is the worst solution. i would probably: - specify the requirements

Re: [PD] repackaging externals on Deken

2017-01-23 Thread IOhannes m zmoelnig
On 2017-01-21 15:11, cyrille henry wrote: > > 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. however, as a side-effectm aby [counter] object loaded

Re: [PD] repackaging externals on Deken

2017-01-23 Thread IOhannes m zmoelnig
On 2017-01-21 11:50, katja wrote: > Choosing a unique name for an external is indeed the best warranty to avoid > conflicts. the problem is of course to create those "unique" names. "context_initbang" could easily nameclash. UUID could be used, but has other drawbacks

Re: [PD] repackaging externals on Deken

2017-01-22 Thread Liam Goodacre
this. From: katja <katjavet...@gmail.com> Sent: 21 January 2017 10:50 To: Liam Goodacre Cc: PD list Subject: Re: [PD] repackaging externals on Deken Liam, Choosing a unique name for an external is indeed the best warranty to avoid conflicts. Not only a future release of a dependen

Re: [PD] repackaging externals on Deken

2017-01-21 Thread cyrille henry
--- *From:* katja <katjavet...@gmail.com <mailto:katjavet...@gmail.com>> *Sent:* 20 January 2017 15:29 *To:* Liam Goodacre

Re: [PD] repackaging externals on Deken

2017-01-21 Thread katja
four versions: one for Windows, Linux Mac, and one without > externals. > > Liam > > -------------- > *From:* katja <katjavet...@gmail.com> > *Sent:* 20 January 2017 15:29 > *To:* Liam Goodacre > *Cc:* PD list > *Subject:* Re: [PD] repackaging externals o

Re: [PD] repackaging externals on Deken

2017-01-21 Thread Chris McCormick
On 21/01/17 02:30, IOhannes m zmölnig wrote: in the meantime i was thinking about extended deken to display a README Sounds cool. Or it could open "README.pd". Cheers, Chris. -- http://mccormick.cx/ ___ Pd-list@lists.iem.at mailing list

Re: [PD] repackaging externals on Deken

2017-01-20 Thread IOhannes m zmölnig
On 01/20/2017 03:50 AM, Chris McCormick wrote: > The best solution to this is currently vapourware. > > It would work like Python's requirements.txt right. in the meantime i was thinking about extended deken to display a README (if present) after unzipping the package. this would at least allow

Re: [PD] repackaging externals on Deken

2017-01-20 Thread IOhannes m zmölnig
On 01/20/2017 05:22 PM, Liam Goodacre wrote: > 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

Re: [PD] repackaging externals on Deken

2017-01-20 Thread Liam Goodacre
9 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 incl

Re: [PD] repackaging externals on Deken

2017-01-20 Thread katja
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

Re: [PD] repackaging externals on Deken

2017-01-20 Thread Jérôme Abel
Hi all, I am looking for the same feature with our project Malinette (http://malinette.info). I could be very nice to make your own bundle of externals with a file with the name of externals and a python script or php which will looking for them with Deken (download, extract). If someone

Re: [PD] repackaging externals on Deken

2017-01-19 Thread Chris McCormick
Hi all, On 20/01/17 03:19, Fred Jan Kraan wrote: 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

Re: [PD] repackaging externals on Deken

2017-01-19 Thread Fred Jan Kraan
Hi Liam, 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

[PD] repackaging externals on Deken

2017-01-17 Thread Liam Goodacre
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