HELP UNSUBSCRIBE I HAVE TRIED TO UNSUBSCRIBE ALREADY UNSUBSCRIBE ME!!!! NOW
On 6/9/16, pd-list-request@lists.iem.at pd-list-request@lists.iem.at wrote:
Send Pd-list mailing list submissions to pd-list@lists.iem.at
To subscribe or unsubscribe via the World Wide Web, visit https://lists.puredata.info/listinfo/pd-list or, via email, send a message with subject or body 'help' to pd-list-request@lists.iem.at
You can reach the person managing the list at pd-list-owner@lists.iem.at
When replying, please edit your Subject line so it is more specific than "Re: Contents of Pd-list digest..."
Today's Topics:
- Re: deken install user experience (Dan Wilcox)
- Re: deken install user experience (Lucas Cordiviola)
- Re: deken install user experience (Lucas Cordiviola)
- Re: deken install user experience (patrice colet)
Message: 1 Date: Thu, 9 Jun 2016 11:36:01 -0600 From: Dan Wilcox danomatika@gmail.com To: Max abonnements@revolwear.com Cc: pd-list@lists.iem.at Subject: Re: [PD] deken install user experience Message-ID: 2BC5638A-617B-4B51-8C87-82867BBDB9E8@gmail.com Content-Type: text/plain; charset="utf-8"
Before the discussion on deken installing libraries for you goes super far, we talked about this curing Chris’ initial deken development and, regarding, auto-magically downloading dependencies:
- Pd developer time is currently limited (Chris & IOhannes were basically
spitballing at that point), so the focus instead was put more on getting the basics working, especially in binary lib upload, search, & install.
- Auto-magic dependency was put into the “nice to have, but possibly a lot
of work to get right” pile as opposed to “must have" pile. If it turns out to be trivial, then by all means someone can propose some code and we can try it out (deken has it’s own GitHub repo after all).
- There is no easy way around the pd-extended kitchen sink -> pd vanilla
barebones + libs transition, [declare] is the preferred way forward in that regard. At least I thought that was agreed upon...
IMO the much bigger issue right now is that we don’t have full coverage of built external deken packages for all the main extended libraries for all platforms yet. If we (I am!) are worried about priority with limited resources, I feel this is much more important right now. We need a big push of people essentially updating these main libs to the pd-lib-builder makefile and then coordinating people on various platforms to build said libs and upload deken packages. The makefile can do that as a makefile target, so it’s relatively easy. After all, how can deken suggest a lib to install when there aren’t that many libs in deken to being with?
One of the great things about deken is that it helps decentralize the kitchen sink. Now, we need everyone to grab a utensil and start scrubbing :)
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jun 9, 2016, at 4:00 AM, pd-list-request@lists.iem.at wrote:
From: Max <abonnements@revolwear.com mailto:abonnements@revolwear.com> Subject: Re: [PD] deken install user experience Date: June 9, 2016 at 3:00:27 AM MDT To: Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com>, pd-list@lists.iem.at mailto:pd-list@lists.iem.at
On 2016년 06월 09일 17:33, Roman Haefeli wrote:
In my ideal world, I write a Pd project, make sure it properly declares what it needs and then people who want to run my project find a list in the documentation with the required externals (with no further explanation how to do that and where to install). After installing the externals from the list, my pd project runs on their box and is able to successfully load the libraries. We're not there yet, see above.
Or even better: the receipient opens the file, Pd realizes that it depends on not installed libraries, prompts "should Pd install the missing libraries x, y and z?" then she/he clicks yes or abort.