monome / maiden

web based editor and repl for norns
GNU General Public License v3.0
47 stars 33 forks source link

manual project add dialog #192

Closed ngwese closed 3 years ago

ngwese commented 3 years ago

allow user to paste a link to a zip archive or git repo

pq commented 3 years ago

See related conversation in https://github.com/monome/norns/pull/1276

ngwese commented 3 years ago

@pq and @simonvanderveldt - I’ve had a long standing card within the project management project (here on GH) to allow a flow similar to the fetch function in matron. I’ve surfaced it here for visibility.

tehn commented 3 years ago

this makes sense!

my adding the norns function was a low-hanging-solution, but also perhaps because some other things came into play. firstly, the maiden meta-commands (which i love, ;restart etc) aren't implemented in maiden-repl nor are the accessible with direct-ws hackery (which i think @simonvanderveldt is doing with vscode?)

if we want to support multiple editors/repl's etc, i'm wondering if it makes sense to centralize some of the process management and script-lib management? these are mostly simple os command calls, but (take ;restart for example) the systemctl call is implemented both in maiden and in matron itself (system > restart) and pending being added to maiden-repl.

this is perhaps roundabout, but should we consider having a separate process that actually executes the calls? (ie, watcher?)

my short list of this sort of meta-management:

i'm not attached to this idea--- just thinking out loud.

ngwese commented 3 years ago

with the exception of the new watcher functionality a vast majority of the above functionality is already in the main maiden command.

at the risk of veering way off topic i do think it would be good to collect up the process management stuff so that it is in one place. the ;restart stuff in the web app is special case handling in the web repl. essentially if the command starts with ; then the input is not sent down the web socket connection and is turned into an HTTP call which is handled by maiden server.

i happened to be looking at the code in watcher this morning and tbh it could be a responsibility easily handled by maiden as well... ....then again i was looking at the watcher because i was tempted to expand its functionality such that it could be used as a way to support not just restart but also switching between running the complete norns stack and something custom...

simonvanderveldt commented 3 years ago

if we want to support multiple editors/repl's etc, i'm wondering if it makes sense to centralize some of the process management and script-lib management? these are mostly simple os command calls, but (take ;restart for example) the systemctl call is implemented both in maiden and in matron itself (system > restart) and pending being added to maiden-repl.

:+1: This seems like a good idea to me. We have some functionality duplicated in places, some not available in all places, this could definitely use some consolidation.

It would probably good to write down some things first, like the list you've written above @tehn, but it might also be good to think about (and possibly group the actions based on) which resources we want to be able to manage (like projects, catalog, but also the running norns stack (or parts of it).

And one question I have would be if there's anything against having the REPL and CLI simply call the HTTP API for these kinds of things?

P.S. This is probably worthy of a new/different issue :)

tehn commented 3 years ago

@ngwese whoa!!!! (re: curl reset) this is both cool and hilarious as a "security problem"

so, (this is not elegant, but) matron could reset itself by doing this curl call. of course, it's not much less complex than the systemctl call, so perhaps we're dwelling on this needlessly.

and as you mentioned, i also started thinking that maiden itself could monitor the keys and actually be the watcher. maybe this is cool? i'm all for less codebases.

maybe the path then is to just try to figure out what all the meta-methods should be and get them working with all the different ways (which is easy if they're http calls!)