Documentation would help to explain the rational but since those haven’t been written yet…
The short version is that the “installed” and “available” views operate fairly independent of each other. The “installed” view treats every directory at the top of the code folder as a potential project. The maiden backend looks at each of the directories and determines if they are managed by Git or not. If they are Git repositories then Git already knows where code came from so the “update” button just turns around and asks Git to grab the latest. If the project directory isn’t manages in Git then “update” looks for information in the catalog to know where to grab updates.
Currently maiden can download projects via Git or as straight Zip files (from and web server).
…but why put “update” on the installed page? Two reasons:
-
If one has installed a project in the past and that project is/was managed with Git and that project is later removed from the catalog, the “update” button is still fully functional.
-
Folks that are comfortable with using Git on the command line and use Git directly via ssh to version their project and push it up to which ever Git server they use. If they have multiple norns devices they can Git clone their project on a secondary norns once (on the command line) then use the maiden “update” button to pull down the latest from there personal Git server.
Broadly speaking the setup is trying to be compatible and possibly even useful for folks that don’t (or can’t) use the maiden ui exclusively.
When projects are installed via the “available” tab the information in the catalog which describes the project (such as description and tags) is copied into the project directory itself. What that means is that if people find it super confusing (or not useful) to treat all directories as potential projects regardless of how they got on the device - we could filter out things that weren’t installed via maiden.
I agree that doing something like this would help reduce confusion. As @tehn mentioned for this round it just came down to time. I’m fairly certain there is a card on the GH project for this effort which talks about this very issue.
Doable and PR’s are always welcome 
In all seriousness the backend is trying to use Git to help in the management if that is an option but not require Git. Everything maiden does today would work if we only had Zip files as a distribution mechanism. One of the things maiden doesn’t actually use (or even understand) is version numbers/hash. It currently lives in the now. For this round it became important not to fall into the trap of trying to write a more full fledged web based git client!
We should start creating issues for these feature requests. I can certainly promote the existing nice-to-haves which correspond to requests which have come up already.
All the debugging tips suggested in other threads still apply even with this new functionality in maiden. If a script isn’t working look for clues/errors in the REPL tabs for both matron and sc. The usual source of problem are typically either:
- The script/project is using a library or engine from another project which isn’t installed.
- The installation resulted in duplicate engine definitions
In either case it if the source of the problem isn’t clear then it is best to post the output you see in the matron and sc REPLs here for other people to see.
One additional point worth mentining:
- If a project is installed that includes an engine one must either SYSTEM > RESET from the menu after the install is complete or type
;restart in the sc REPL in order to get supercollider to recompile its class library.
