On Wed, Sep 01, 2021 at 11:50:15AM -0400, Michael Gogins wrote:
> I think it's time to do this. It would solve most of the vexing issues with
> a plugins repository.
> 
> TL;DR: This is built into Csound. It automates UPLOADING extensions, and it
> automates FINDING and INSTALLING extensions. Unlike Steven Yi's proposal
> this does not automate BUILDING extensions, contributors are still
> responsible for that. But that could certainly be added later in the form
> of GitHub actions.
> 
> The details...
> 
> Here's the current status of Csound versus its main alternatives regarding
> contributed extensions:
> 
> -- Csound (open source), contributors maintain and distribute their own
> extensions. Partial exceptions: plugins and risset.
> 
> -- Max/MSP (proprietary but most widely used), built-in package manager for
> contributed extensions.
> 
> -- ChucK (open source), plugins repository for contributed extensions.
> 
> -- Pure Data (open source), built-in package manager for contributed
> extensions.
> 
> -- Purr-data (open source), many extensions are contributed to the main
> repository by pull request and maintained there.
> 
> -- Supercollider (open source), plugins repository for contributed
> extensions, SuperCollider language extensions are in
> https://github.com/supercollider-quarks.

Note that in the SuperCollider case this is only for language extensions: code that doesn't need to be built, only present in a directory. The package manager is largely a GUI for `git clone`ing repositories and managing transitive dependencies. There's no support for anything that needs compilation, e.g. unit generators.

Also, I'm not sure that with the benefit of hindsight the SC community would have built the system they did. There are maintenance burdens and limitations to growth, as well as issues with incompatible version dependencies.

I'd also be quite concerned about the security of downloading third-party precompiled binaries.

Tom

> 
> Proposal:
> 
> Csound gets a built-in package manager (cspm) for plugin opcodes, fgens,
> and extensions written in Csound languages (e.g. UDOs and instrument
> definitions).
> 
> This is a csound utility program/opcode. It is loosely modeled on the
> existing risset package manager, vcpkg, and deken. Simply using vcpkg would
> work, but would force contributors to jump through unnecessary hoops.
> 
> The package manager maintains contributions in a GitHub repository named
> csound-extensions, licensed LGPLv2.1.
> 
> The package manager commands are:
> 
> --contribute - upload a contribution to the contributor's account in the
> csound-extensions repository. The contribution must consist of a directory
> in a standard format containing a package manifest and pre-built package
> contents. The contributor must have a GitHub account.
> --list - list packages in the package repository.
> --search - search in the package repository manifests.
> --information - print the package manifest.
> --install - install packages if the platform is supported.
> --dependencies - list dependencies of packages.
> --remove - remove packages.
> 
> A Csound extension package is a zip file with a .cse filename extension in
> the following structure based on Csound environment variables qualified
> where necessary by runtime architecture (specified as for vcpkg triplets,
> e.g. x64-windows, x64-osx, x64-linux).
> 
> manifest.json
> SFDIR/ for soundfiles.
> SSDIR/ for samples.
> SADIR/ for analysis files.
> INCDIR/ for .csd, orc., and include files.
> OPCODE6DIR/triplet/ for loadable modules.
> OPCODE6DIR64/triplet/ for loadable modules.
> MFDIR/ for MIDI files.
> deb/ for Debian packages.
> exe/ for Windows installers.
> dmg/ for MacOS installers.
> apk/ for Android installers.
> npm/ for NPM packages.
> NODE/arch for binary Node.js and JW.js addons.
> 
> Extensions with third party dependencies are the main problem. Rather than
> solve this problem, either (a) the package contains an inner package that
> manages its own dependencies such as a vcpkg package or a Debian package,
> or (b) the manifest simply lists all third-party dependencies.
> 
> The manifest format is:
> {
>   name: "package_name";
>   version: "1.2.3.alpha";
>   author: "author name";
>   license: "standard license name";
>   description: "What is this extension for?";
>   repository: "where if anywhere is the source code repository?";
>   tags: "comma-delimited list of searchable tags.";
>   dependencies: {
>     "triplet_1:" [list of dependencies];
>     "triplet_2": [list of dependencies];
>     ...
>   };
>  };
> 
> It is not necessary to list the contents of the package, that can be
> inferred from the archive.
> 
> As I mentioned, it would be possible to add automated builds for all
> supported platforms later, and this of course would also require creating
> Git submodules or source directories for each contribution, but what I have
> outlined should be doable pretty quickly.
> 
> Regards,
> Mike
> 
> 
> 
> 
> 
> The package manager uses the GitHub API to upload contributions from a
> contributor's package directory as a pull request. And it uses the GitHub
> API to download packages, which it then installs according to the manifest.
> 
> Regards,
> Mike
> 
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com