I would welcome advice about a strategy to deploy a monolithic "same everywhere" version of PD. Ideally, this would be with a set of libraries that are fixed at a given version and work the same on MacOS and Windows.
Pd-vanilla + a list of libraries to install via Deken would work.
Alternatively, would there be a way for me to install PD-vanilla and Deken install some libraries in such a way that I can deploy a copy with all dependencies in a single folder?
If "single folder" is a hard requirement, then Christof's suggestion of using (abusing) the extra directory would work, albeit is considered bad practice at this point. This hides the library mechanisms form the user and almost guarantees they will be *fully* dependent upon your custom distribution as opposed to providing them a short how-to on using deken and encouraging usage of [declare]. The distributed library approach is the future at this point, so I see less of a reason of building a "custom extended." At the most, you could lobby for an "extended" deken metapackage which installs a long list of common libs.
Pd vanilla has a newish "Documents directory" feature which can automatically create a "Pd" directory in the user's home/Documents directory. This also creates an "externals" subdirectory which becomes the designated place for deken to install to. Naturally, you can manually copy all externals there as well. Although this feature is annoying* to advanced users, it was a major suggestion by a couple of people on the forum who, like yourself, teach Pd classes. Having taught myself, I also saw the utility of providing a "patch & external home" akin to Processing's sketch directory.
(* The documents directory feature is *very* easy to disable, either from the welcome dialog or within the Path dialog.)
In essence, the constraints have to do with the fact that software installations are managed by our IT team, so I need to give them a specific set of instruction and be reasonably guaranteed that the results will work. Neither students (nor I) can I install software on those machines.
I assume each user account has write access it its own home folder? If so, either Pd can create the directory when they first run Pd and/or you can instruct the students to place the folder themselves. (Which reminds me that we could add a button to automatically open the folder from the Paths dialog.)
The workflow would be like this:
- Install Pd:
- macOS: copy Pd-0.49-2.app somewhere win the user home dir, default place for this would the per-user Applications directory: ~/Applications
- Windows: copy Pd app dir somewhere in the user home dir, ~/Desktop is fine as long as they can find & launch it
- Create Pd Documents Dir:
- automatically on first run: Pd will ask when it is first run if ti should create this directory;
- manually in Pd: On the Path dialog and enable the Pd Documents directory if it's not already.
- Install libraries:
- without deken: You prepare an "externals" dir with the libraries you want them to have access to and provide it as a zip, etc. Then have them copy these into the Pd document dir.
-with deken: Give them a list of library names to install; & walk them through installing the list via deken. It will automatically install them to the Documents/Pd/externals dir
If it were me, I would actually provide the Pd documents dir within a zip with both externals *and* prepared lesson & example patches, ready to go. When the documents dir is enabled, the GUI open & save dialogs automatically start from with in the Documents dir. So the students download Pd, place the zip in their ~/home/Documents and should be ready to go. You then need to show them how to use [declare], but that can be within a lesson patch. :)
If IT is not complete unhelpful, you could wrap up these steps into a script they could run. They would probably be more inclined to run it as opposed to doing things manually. :) OTOH, I will repeat that it's a good idea to familiarize students to the libraries process.
It's also important to me to insure that students can bring their work to and from university to home, and that the work in progress that send me opens and works on my machine.
All the more reason, in my opinion, to teach them how to install libraries and use [declare].
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
If it were me, I would actually provide the Pd documents dir within a zip with both externals *and* prepared lesson & example patches, ready to go.
+1
Gesendet: Samstag, 25. Mai 2019 um 11:05 Uhr Von: "Dan Wilcox" danomatika@gmail.com An: "Martin Dupras" martindupras@gmail.com Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] Advice on PD versions for classroom deployment
I would welcome advice about a strategy to deploy a monolithic "same everywhere" version of PD. Ideally, this would be with a set of libraries that are fixed at a given version and work the same on MacOS and Windows. Pd-vanilla + a list of libraries to install via Deken would work. Alternatively, would there be a way for me to install PD-vanilla and Deken install some libraries in such a way that I can deploy a copy with all dependencies in a single folder? If "single folder" is a hard requirement, then Christof's suggestion of using (abusing) the extra directory would work, albeit is considered bad practice at this point. This hides the library mechanisms form the user and almost guarantees they will be *fully* dependent upon your custom distribution as opposed to providing them a short how-to on using deken and encouraging usage of [declare]. The distributed library approach is the future at this point, so I see less of a reason of building a "custom extended." At the most, you could lobby for an "extended" deken metapackage which installs a long list of common libs. Pd vanilla has a newish "Documents directory" feature which can automatically create a "Pd" directory in the user's home/Documents directory. This also creates an "externals" subdirectory which becomes the designated place for deken to install to. Naturally, you can manually copy all externals there as well. Although this feature is annoying* to advanced users, it was a major suggestion by a couple of people on the forum who, like yourself, teach Pd classes. Having taught myself, I also saw the utility of providing a "patch & external home" akin to Processing's sketch directory. (* The documents directory feature is *very* easy to disable, either from the welcome dialog or within the Path dialog.) In essence, the constraints have to do with the fact that software installations are managed by our IT team, so I need to give them a specific set of instruction and be reasonably guaranteed that the results will work. Neither students (nor I) can I install software on those machines. I assume each user account has write access it its own home folder? If so, either Pd can create the directory when they first run Pd and/or you can instruct the students to place the folder themselves. (Which reminds me that we could add a button to automatically open the folder from the Paths dialog.) The workflow would be like this:
- Install Pd:
- macOS: copy Pd-0.49-2.app somewhere win the user home dir, default place for this would the per-user Applications directory: ~/Applications - Windows: copy Pd app dir somewhere in the user home dir, ~/Desktop is fine as long as they can find & launch it 3. Create Pd Documents Dir: - automatically on first run: Pd will ask when it is first run if ti should create this directory; - manually in Pd: On the Path dialog and enable the Pd Documents directory if it's not already. 2. Install libraries: - without deken: You prepare an "externals" dir with the libraries you want them to have access to and provide it as a zip, etc. Then have them copy these into the Pd document dir. -with deken: Give them a list of library names to install; & walk them through installing the list via deken. It will automatically install them to the Documents/Pd/externals dir If it were me, I would actually provide the Pd documents dir within a zip with both externals *and* prepared lesson & example patches, ready to go. When the documents dir is enabled, the GUI open & save dialogs automatically start from with in the Documents dir. So the students download Pd, place the zip in their ~/home/Documents and should be ready to go. You then need to show them how to use [declare], but that can be within a lesson patch. :) If IT is not complete unhelpful, you could wrap up these steps into a script they could run. They would probably be more inclined to run it as opposed to doing things manually. :) OTOH, I will repeat that it's a good idea to familiarize students to the libraries process. It's also important to me to insure that students can bring their work to and from university to home, and that the work in progress that send me opens and works on my machine. All the more reason, in my opinion, to teach them how to install libraries and use [declare].
Dan Wilcox @danomatika[http://twitter.com/danomatika] danomatika.com[http://danomatika.com] robotcowboy.com[http://robotcowboy.com] _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
As a follow-up:
You and/or IT don't need to run Pd to create the directory, you can just create it outside of Pd. Of the feature is enabled, Pd simply checks if the folder is there. If it's not, Pd asks you via a dialog if you want to create it, in which case you can or simply disable the feature.
This would mean deploying you set could be as simple as:
- Install Pd
- Unzip your prepared Pd documents dir into the user's home/Documents directory.
I'm not sure but, alternatively, there might be a way to invoke deken to install libraries from the command line. If not, this is a feature we should look into adding as it would make this process pretty easy while still preserving the library mechanism instead of dumping things inside of "extra."
Addenda:
Relevant discussion into creating this feature is: https://github.com/pure-data/pure-data/pull/152 https://github.com/pure-data/pure-data/pull/152
You could also ask Alexandre Torres Porres and Mark Grimm who have used it in the classroom a couple of years now.
On May 25, 2019, at 11:05 AM, Dan Wilcox danomatika@gmail.com wrote:
Pd vanilla has a newish "Documents directory" feature which can automatically create a "Pd" directory in the user's home/Documents directory. This also creates an "externals" subdirectory which becomes the designated place for deken to install to. Naturally, you can manually copy all externals there as well. Although this feature is annoying* to advanced users, it was a major suggestion by a couple of people on the forum who, like yourself, teach Pd classes. Having taught myself, I also saw the utility of providing a "patch & external home" akin to Processing's sketch directory.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 5/25/19 11:35 AM, Dan Wilcox wrote:
I'm not sure but, alternatively, there might be a way to invoke deken to install libraries from the command line. If not, this is a feature we should look into adding as it would make this process pretty easy while still preserving the library mechanism instead of dumping things inside of "extra."
deken find and deken install are already implemented (obviously
requiring the deken cmdline tool, as opposed to the GUI plugin for Pd).
you can even use deken install -r requirements.txt to install a couple
of libraries from a single specification file.
however, i'm not entirely sure whether this solution would be the simplest one for your IT department to implement.
On 5/25/19 11:05 AM, Dan Wilcox wrote:
If "single folder" is a hard requirement, then Christof's suggestion of using (abusing) the extra directory would work, albeit is considered bad practice at this point.
i'm not really convinced that this is an *abuse* of the extra/ folder. "extra/" is the folder where you would put all the externals that "come with this installation of Pd", which is exactly what the OP was looking for.
especially:
This hides the library mechanisms form the user and almost guarantees they will be *fully* dependent upon your custom distribution as opposed to providing them a short how-to on using deken and encouraging usage of [declare].
i don't see how this is flawed by using extra/. putting stuff into extra/ will still require you to use [declare] (or any other mechanism to load the libraries, very much the same as if you put them into ~/Documents/Pd/extra).
if they are properly declaring dependencies on used libraries (whether installed to extra/ or ~/Documents/Pd or /tmp/foobar), they don't depend on your distribution at all (unless of course you are shipping them custom, non-deken externals; but i guess this is not the case here).
and of course they can still use deken themselves (and have their deken install directory set to ~/Documents/Pd/ if you insist)
gfdsar IOhannes
-
Christof Ressi -
Dan Wilcox -
IOhannes m zmölnig