Can't switch between mojo specs easily

[Michael Nelson]

A developer should be able to pull (or switch to) a spec branch, and run one command, to run a spec.

Steps to repro:
 1) Pull a mojo spec branch (or switch to a different spec) - mojo-u1-project-A
 2) `mojo run`

Expected result: mojo runs the main manifest for mojo-u1-project-A
Actual result: A bunch of env vars (at least MOJO_STAGE=ols/mojo-u1-X/devel, MOJO_WORKSPACE and MOJO_SPEC) need to be defined / exported.

 3) debug/develop, then destroy juju env and rebootstrap
 4) cd/switch to a different spec - mojo-u1-project-B
 5) `mojo run`

Expected result: mojo runs the main manifest for mojo-u1-project-B
Actual result: A bunch of env vars need to be redefined / exported, and can result in contamination from mojo-u1-project-A

This isn't an issue for deployments/IS, as a deployment is setup once, env exported, and things don't change (at least, you don't switch to a different spec in that env). But for a typical (?) developer workflow, it isn't great.

In the past, we've worked around this by using a Makefile to define the required variables without needing to export them to the session, so we can switch branches and just run `make run`. But this has then leaked into some deployment commands (ie. currently `make manifests/upgrade-deployment` rather than just using `mojo run --manifest-file manifests/upgrade-deployment` with the correct env vars exported). And so, it's important from IS pov, that at least for all deployment related tasks, we're not using Makefiles.

[Michael Nelson (michael.nelson)]

AFAICT, the best way forward is simply for us to continue to use a Makefile for development, but move all the env vars out into a (stage specific) envrc in the spec that can alternately be sourced. In development, our Makefile will just ensure it's sourced before running equivalent mojo commands, while on staging / production (or in development if we choose to test), we can manually source the env file and run with mojo directly (the same commands).

FWIW, I've been investigating a way for us devs to be able to use mojo directly (without a Makefile) - with mojo automatically sourcing the relevant env file, but afaict, it's pretty useless, as for mojo to be able to *find* the correct env file in the first place, it still needs MOJO_STAGE=ols/mojo-your-spec-name/stage, and MOJO_WORKSPACE and MOJO_SPEC.. Even if we hack around to derive MOJO_STAGE from the CWD iff MOJO_STAGE isn't defined, we'd still need to either define workspace and spec, or load an env from the spec in the CWD (both of which aren't great options).

[Michael Nelson (michael.nelson)]

The more I look at this, the more I think it's OK that mojo (a deployment/ci tool) requires these env vars, and that it's OK that for development work, we utilise a Makefile for use only in devel, which sources a devel-only envrc (which may itself include a general envrc which can be used for deployments). ie.:

./envrc # <- common env vars which can be sourced for deployment setups
./devel/envrc # <- includes ../envrc

Makefile just a convenience wrapper around mojo commands that sources ./devel/envrc for development only.

[Tom Haddon (mthaddon)]

I kind of see this as similar to setting up a juju environment, and I think mojo could provide some better tools to help here (such as a "mojo set-up-env" command or "mojo --remember" so you only have to pass all the options once, and "mojo switch" to list/switch
between known mojo environments).