System for patch authors to specify externals dependencies for end users of a patch.

[chr15m]

This would work like Python's requirements.txt or Ruby's Gemfile or Node's packages.json and allows a patch author to specify exactly which externals their patch depends on.

See also #84.

The patch author should do three things:

1. Create a pd-dependencies.txt to go with their patch.
2. In their patch instantiate [declare -path pd-dependencies/zexy] for example.
3. Instantiate a [deken-dependencies] object in their patch.

(maybe 2 & 3 could be combined)

I suggest a format as follows for pd-dependencies.txt:

# Dependencies for mypatch.pd
freeverb~-v0-0extended
zexy-v0-0extended
http://puredata.info/Members/zmoelnig/software/cyclone/0-0extended/cyclone-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar.gz

Note in this example the patch author has specified the exact URL for the 'cyclone' externals set.

The end user can now:

1. Send the message "install" to the [deken-dependencies] object.
2. This will look for and open pd-dependencies.txt; and
3. Create a new folder next to the patch called pd-dependencies; and
4. Download & unpack each listed deken package into the pd-dependencies folder.

Suggest we start with the simplest possible iteration that works and don't try to solve every problem in an automated way.

@millerpuckette @umlaeute

[umlaeute]

hmm, i think the dependency handling should be either in the patch or outside.
i would probably leave (2) ([declare]) alone and either:

• have an object [deken-dependencies] that takes the versioned dependencies as arguments
  OR
• add a menu-entry that get's enabled if there is a pd-dependences.txt alongside the patch.

my gut feeling prefers the menu (as this would allow a nicer fallback if the dependency resolver is not installed).

[umlaeute]

regarding the format: i guess JSON would be great (if parseable on the reader-side (think tcl!))

as for the pd-dependencies folder: do you suggest to hardcode this name? please don't. i would suggest to hardcode as little as possible on the file-system level. (and there is already a hardcoded file pd-dependencies.txt).

maybe add an (optional) argument to the dependency line that specifies where the external ought to be unzipped.

 # Dependencies for mypatch.pd
 freeverb~-v0-0extended
 zexy-v0-0extended zuxel

[electrickery]

Starting with the simple part: a file containing a list of objects names and descriptions next to the zipped/tarred library on puredata.info could help find objects within libraries via deken. Assuming a tcl-json parser could be found/constructed, the file could look like the example below. Creating the file should be a distributors' task and be decentralized. The information could be harvested from the META sub-patched Jonathan added to most pd-extended help-patches years ago.

A deken module retrieving the data and make it searchable could be next (I'll try).

Complete file at: http://puredata.info/Members/fjkraan/software/tof/0.2.0/tof-v0.2.0-Objects.json

{
 "library" : "tof",
 "author" : "Thomas Ouellet Fredericks",
 "version" : "0.2.0",
 "repository" : "https://github.com/electrickery/pd-tof",
 "objects" : [
  {
   "object" : "animate",
   "description" : "animate the object boxes inside a patch"
  },
  {
   "object" : "argument",
   "description" : "outputs the patch's creation arguments individually. "
  }
 { ... }
 ]
}

[umlaeute]

i did a (brief) search for a json-parser in tcl a few months ago and it didn't reveal much.
i think that having such a thing might be a pre-requisite for this kind of functionality (otoh, it could also be the server that would parse the json-file)

[electrickery]

There is a package that puts a json structure in a dictionary/list contraption, and it appears to work, at least with the current version of the online json example. It is is quite picky on which character to escape with either one or two backslashes.

oDeken.tcl.TXT

tclsh odeken.tcl <tof-objectName>

[millerpuckette]

I'm windering if this isn't too big a tool for the job - rather than have
deken depend on an external tcl/tk package, would it be possible to use a
simple text file format, like

object-name library

...

?

cheers
Miller

On Mon, Jun 27, 2016 at 12:47:45PM -0700, Fred Jan Kraan wrote:

There is a package that puts a json structure in a dictionary/list contraption, and it appears to work, at least with the current version of the online json example. It is is quite picky on which character to escape with either one or two backslashes.

oDeken.tcl.TXT

tclsh odeken.tcl

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#122 (comment)

[electrickery]

That would simplify it a lot. It would be nice to have some object and library meta-data available, but it isn't an essential part of the object search.

[chr15m]

@millerpuckette wrote:

simple text file format

If I was writing the code this would be my preference.

@electrickery I think that some "object and library meta-data" information is not mutually exclusive from "simple text file format". It's probably a matter of deciding what are the really salient non-redundant bits of info and then allowing optional extra fields in the simple text file format.

[chr15m]

Python's requirements.txt is exactly such a simple text file format.

https://pip.readthedocs.io/en/1.1/requirements.html

Here's what it looks like:

somelib
Framework==0.9.4
Library>=0.2
-e svn+http://myrepo/svn/MyApp#egg=MyApp

You can see above how it's possible to specify:

• A dependency by name only.
• A dependency by name with some exact required version.
• A dependency by name with some minimum version.
• A dependency from a repository URL (for Pd this could only work for abstractions but could still be useful).

I'm not even sure if we need to get this complicated but I think it's basically a good model to follow.

[umlaeute]

i think this thread was hijacked (and i didn't realize it and took the bait)

• a requirements.txt mechanism (as discussed in this thread) helps installing known-to-be-used libraries
• the proposal by @electrickery would help finding out which library is being used (or, which library might contain a given functionality; it's related to dekenception: check missing objects from patch and suggest to install libraries #84)

the two are somewhat related (the 2nd would help creating the 1st) but rather orthogonal.
i think a separate issue should be opened about @electrickery proposal.

[electrickery]

@umlaeute
Sorry, being confused is one of my better developed talents. Issue #84 also drifted to requirements so a new issue might be best.

[umlaeute]

yeah, sorry about mentioning #84 - while it is related i did not intent to suggest to move the proposal over there. however, i see that this is the way one would read my post.

for the reference, the new ticket for an object-search is #133

[mxa]

This issue is over 2 years old, but still interesting conversation. From a user perspective, wouldn't it be much better if Pd would just attempt to open a file, chencs for objects whcih can't be created, finds in a database which libraries offer them (for ambiguous ones taking clues from [declare -lib xy] objects if present) and then offers the user to download and install them via deken. My apologies if I have missed something.

[umlaeute]

@mxa but your suggestion is #84, no?

[mxa]

@umlaeute indeed it is.