[PD] Deken library management. Was: [pdconv16_r] Topics: Deken/Core Objects/Website/Community Involvement

[Christof Ressi]

> Deken as it is right now, you
> pretty much have to know the name of the library you want to install,
> and what it does/what it contains. As a new user, I'd find that pretty
> daunting. 

very good point!

> Thus, I'd propose: a list of keywords for the library (including object
> class names), version number, category (if applicable), author, and a
> short description. 

that would make a lot of sense. maybe this info could then be synced with https://puredata.info/downloads/by-category/library so there would also be an up-to-date online ressource (without the need of running Pd)?

> Gesendet: Montag, 31. Oktober 2016 um 13:11 Uhr
> Von: "Derek Kwan" <derek.x.kwan at gmail.com>
> An: "Fred Jan Kraan" <fjkraan at xs4all.nl>
> Cc: pd-list at lists.iem.at
> Betreff: Re: [PD] Deken library management. Was: [pdconv16_r] Topics: Deken/Core Objects/Website/Community Involvement
>
> > It would help the discussion if there was an inventory of actual problems
> > the metadata would solve. There was a discussion about this on the Github
> > deken-list, which (probably) went nowhere because of this.
> 
> This metadata would potentially solve issues with updates (I'll discuss
> this later) and just general ease-of-use. Deken as it is right now, you
> pretty much have to know the name of the library you want to install,
> and what it does/what it contains. As a new user, I'd find that pretty
> daunting. I don't know what external libraries are there for Pd, I don't
> know what any of them do, I don't know when they were last updated so I
> don't know how old these libraries are. Even as an experienced user, maybe
> I'll forget which libraries have sample-length delays, or bandlimited
> oscillators or limiters (you don't need to tell me this, I already know =P) 
> 
> At least with pd-extended, everything was just there and you could dig through
> the Pd browser. In a post-extended world, we're just throwing users into the deep
> end and hoping for the best. At least in my experience, I've seen a lot of
> people asking how to install x library or wondering what library they
> can download for some certain functionality, and a lot of people just
> resorting to pd-extended because it's easier. I think as contributing
> members to the Pd community, it's our job (or at least it'd be nice) to
> make things easier for newcomers. Heck, even in the pd-extended era, it
> was kinda hard to tell what all the libraries did and what object
> classes they had just from the sheer scale of it all.
> 
> Taking a page from Processing, the Contribution Manager has a filter
> search where you can look up keywords, the version number, a short
> description of what the library does, and the author. Additionally, you
> can install, update, and also remove from the same window. Like if I
> type in "audio" into the filter, the list that used to display all the
> libraries is just displaying Beads, Loom, and Minim. There's also a
> dropdown menu to sort by category, such as Animation, GUI, Hardware,
> etc.
> 
> Thus, I'd propose: a list of keywords for the library (including object
> class names), version number, category (if applicable), author, and a
> short description. 
> 
> 
> > With the current update policy of Pd-vanilla (add new functionality without
> > breaking the existing one), not much issues arise between the core and
> > externals. The best strategy for building externals is to anticipate
> > differences in vanilla versions, implement workarounds if possible or fail
> > gracefully if needed.
> 
> I suppose I'm more concerned about updates to external libraries so it
> migth be a little off-topic =). But here's a case, say I have library x
> v 2.0 and it's buggy as heck and a v3.0 happens to get uploaded. One
> nice thing would be to have Deken tell me about that (esp if I have
> something like 20 libraries installed on my computer, it gets kinda hard
> to keep track of it all) but perhaps more importantly and realistically,
> I'd like to be able to download the update without having to mess with
> the current installation and not have to worry about duplicates. I'm
> just trying to think of smarter library management in a post-extended
> world and I suppose I'm thinking of pd-l2ork too and how to go about if
> one library gets updated inbetween pd-l2ork versions, but this also
> applies to using Pd Vanilla as well.
> 
> > A version number would be a good idea, but how many external-packages depend
> > on other entities than Pd-vanilla? Having more information available before
> > downloading would be nice, and this could already be implemented as an
> > extended deken-plugin.
> > 
> > Debian packages also have dependencies listed, but that is quite a different
> > scale of complexity.
> > 
> > Without some actual problems, it will be hard to devise a solution to solve
> > them.
> 
> Here's a case: Say I have this piece that requires library1,
> library2,... up to libraryn that are all avaliable compiled for various
> platforms on deken. I'm on linux and I want to share this piece with a
> group of people who are on MacOS, Windows, Raspberry Pi's, etc. What's
> the best way to go about this? Potentially I can just include the
> binaries for every single platform and have one thing I can ship out, I
> can on my own make platform independent distributions and make those
> available, or potentially a third option (my proposed idea), have a
> package manifest with a list of the libraries and their build versions,
> and have deken handle the versioning and platform-specific binaries by
> handing the package manifest over to deken like how you can use a
> package.json file in a node.js project to contact a central repository
> and download everything with their proper versions via npm install.
> Especially if these patches with library dependencies I want to
> distribute are didactic material, I want it to be as easy and painless
> as possible, almost as easy as downloading pd-extended in the past.
> 
> For the local vs global install issue , maybe this piece requires library3
> v2.0 and doesn't work with the current library3 v3.0 because something broke.
> I want to be able to use library3 v2.0 with this piece but I don't want to
> screw up my Pd install and have both versions in my general Pd
> searchpaths (there would also be potential nameclashes with the
> the old and new objects but ignoring that for now... =P). Also maybe I use
> the majority of the libraries with only this one piece only so I don't want
> globally install these libraries.
> 
> ------------------------------------------------------------------
> 
> Sorry if none of this made sense, a bit sleep-deprived and it's late
> =) I think my updates argument was the weakest one and I'll have to
> think about that more... And I suppose this discussion kinda is
> tangentially related to pd-vanilla development, but Deken is a part of
> the Pd Vanilla distribution now and I think library management in a
> post-extended world is a worthwhile topic.
> 
> -- 
> Derek Kwan
> www.derekxkwan.com
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>