UI for installing scripts in dust

[robbiecloset]

I started a discussion in the norns ecosystem thread on the subject of providing an Atom-like package installation interface in maiden.

---

As a developer of scripts for norns, I would upload a functioning script as a separate project on github, adhering to an established project structure (related to discussion here perhaps).

When the script is complete & publicly available, I would open a pull request against maiden adding metadata about my script to a growing list of community provided scripts. This would in effect "publish" the script.

This could be json. This could be yaml. This could be txt.

Assuming json, an example could be:

// scripts.json
[{
  "name": "foulplay",
  "description": "euclidean sample instrument with trigger conditions.",
  "guid": "notjustmat/foulplay"
}, {
  "name": "rebound",
  "description": "a kinetic sequencer",
  "guid": "nf/rebound"
}]

As a non-developer user of norns, I would use maiden to browse available published scripts. I would install scripts & keep them up to date at the push of a button.

---

As I mentioned in the forum, I don't think that the overhead of this is very significant. We would still be able to leverage git & github under the hood, while giving non-technical users an interface to explore new scripts, without having to put all scripts straight into dust.

There is obviously room for continued improvement here as well. The above represents a solid MVP in my opinion.

Happy to be told that this isn't the direction we want to move in, thought I'd share some of my thinking on it though!

ps- I know that #115 is already a thing. I feel like the above is a different proposal though, because here I am advocating a strategy that keeps the majority of scripts out of dust. Want to call it out though (thanks @jasonw22) because certain of the objectives overlap.

[jlmitch5]

@robbiecloset Cool ideas. Not invested in #115 115 (and have a lot of stuff coming up so I don't know when I'd be able to work on the implementation of that).

When the script is complete & publicly available, I would open a pull request against maiden adding metadata about my script to a growing list of community provided scripts. This would in effect "publish" the script.

I think I would have the metadata and any sort of dev PR flow be in dust or some new repo even if the script is not). Dust is essentially the community shared library of norns content. Maiden is about the editor.

Though, if the dev has to open a PR to update something, is the experience really that different than storing their script within dust?

As I mentioned in the forum, I don't think that the overhead of this is very significant. We would still be able to leverage git & github under the hood, while giving non-technical users an interface to explore new scripts, without having to put all scripts straight into dust.

What's the interface and how do user's interact with it?

[ngwese]

I think this ticket or something like it is worth exploring once norns 2.0 is out and everyone is collectively happy with the new structure for dust.

[robbiecloset]

Yeah, I was kind of thinking the same, since I'm not yet sure what dust will look like post-2.0, or whether or not 2.0 itself includes an upgraded mechanism for managing / installing scripts.

Still really interested in helping with the general experience of managing / installing / trying out scripts though!

[ngwese]

I've started to explore this on the now inappropriately named dust-2 branch....

Roughly speaking I’m starting to converge on the notion of a “catalog” of scripts. Basically a JSON manifest. The catalogs can be manually built or generated from some source - I have logic to build a catalog from the lines library topics that have the norns tag. Once gathered one should be able to install a script (directory) by name (say “mlr”). My current aim is to allow pulling from multiple catalogs so that if people really want to maintain less public or curated lists they can.

maiden will be taught to detect if an installed script/project is a git repo. If so I expect to support git pull and a more forceful version that overwrites local changes. If the install does not appear to be a git repo then the assumption can be that it’s a zip archive and grab whatever is listed in the catalog again.

Challenges: I have a crude heuristic to pick/derive which of the many links in a lines post is the project link. If multiple versions are posted within the same topic it will be very difficult to pick the “right one” without defining some structure - for example expecting that link title for the script be named after the script plus semver info (say “mlr-1.0.0”). The second challenge is that there isn’t really a common and robust way to tell what is available in the catalog is newer than what is on the device...

The initial push is to work this out by adding commands to the maiden cli then move to expose it in the web app.