Develop a pluggable architecture for search & install so that packaging systems can provide hooks.

[umlaeute]

it would be great to allow for multiple backends for doing the search/installation of packages.

• a backend for puredata.info/dekenpackages
• a backend for apt search apt for packages #42
• a backend for github-releases search github for packages #41
• a backend for sourceforge-files search sourceforge for packages #40
• ...

[umlaeute]

i mainly opened this ticket to collect ideas on how to design the framework for such backends

[danomatika]

This makes me think deken should cache downloaded info, like apt.

[umlaeute]

doesn't it? at least for me the zip-files in my ~/pd-externals folder are not deleted (but then, for some to-be-investigated reasons, the zip-file doesn't really gets extracted, and instead a xarchiver and EasyTAG [sic!] open up...)

but yeah, the files are re-downloaded, which could be avoided.

[chr15m]

See #10.

[umlaeute]

search

searches for a given library, and returns all matches

arguments:

• search string (can be empty)

returned data:

• a set of
  • description of the package (file), so the user knows what they are to install
  • trust establishing description: so the user knows who provided that binary
  • how well does the given package match the host?
  • an ID, that can be passed to the install routine

the host sorts the returned values along the match axis (and probably along the date/version axis)

install

installs a given library

arguments:

• ID (as returned by search)

returned data:

• success?
• installation progress
  • directly write into the deken-window? (requires to pass $mytoplevel.results)

[chr15m]

Looks good to me. It would be good for the backend interfaces to not have to care if called in the Pd gui or from the command line via tclsh #8.

[danomatika]

By cache, I mean caching the package info from puredata.info, not the zip files. This way you could see whats available even if offline.

[umlaeute]

ah i see; should probably go to another ticket.

[chr15m]

Yep and at this stage I don't see a compelling reason to do the work of caching that information locally since you can't actually download packages without a connection. See #31.

[umlaeute]

TODO: provide a way to (de)select backends in the gui.

[umlaeute]

instead of an ID, the search could return a command-to-install directly (something like [deken::download https://example.com/foo-external.zip]