@AndyRussG cool - I wondered if it would make sense to call setup.sh with switches like --no-composer or just to call more specific scripts directly

It feels to me that running composer install (and npm install where appropriate) should happen automatically when we freshly clone a repo. After that we should can just use docker-compose exec to update as necessary.

I would like to be able to run it by codebase, eg leave payments alone but destroy and rebuild the civi db and code

Another use case: update all (or specified) codebases to the latest master, and only stop if uncomitted local changes found, maybe?

Here are some general thoughts about how I'm imagining this could go:

• Break out the scripts; for example, one is clone source code, another is reset containers, another is get dependencies via composer or npm, another is db-related setup.
• Each of those scripts would have command-line arguments to tell it which codebases to operate on, and which kinds of questions to answer yes or no as a default.
• Create other, script-calling scripts, which would be like set "recipes" that combine the above scripts to do a specific common task. For example, one such recipe could be for a fresh install situation; another could be to return everything to a pristine state, and only ask a quesiton if we're about to blow away existing uncommitted code; another could update all or certain the codebases to the latest master. These more general scripts could also have arguments to tell them to operate only on specific codebase(s).

In general, hopefully all of the more specific scripts and the script-calling scripts could have options where you just tell them what to do and you don't have to answer any more questions or think about it any more, unless absolutely necessary.

Thx much!! :)

Quick note for a feature here: somewhere or other, composer should be run automatically, maybe when there's no vendor directory?

Another quick feature idea note: script to update source code could also check the branch (so if you're on a different branch you made to create Gerrit changes, it could switch you back to master).

Also, we could automatically set up the smashpig repo in the payments vendor directory.

We might want to crib what the vagrant folks did with vagrant git-update:
https://github.com/wikimedia/mediawiki-vagrant/blob/master/puppet/modules/mediawiki/templates/run-git-update.erb

This seems like a big task, with many possible ways forward, so here's a subtask for initial scoping out:

T287028: Docker dev setup: scope out use cases, requirements and command-line UI to replace setup.sh.

Thanks much!!! :)