> 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" <[email protected]> > An: "Fred Jan Kraan" <[email protected]> > Cc: [email protected] > 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 > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
