[feat] module to import appropriate .env

[heaths]

It's great using azd to provision resources and being able to load the .env files using godotenv or whatever, but it would be even easier in projects using azd this way if we provided a library to make it easier e.g.,

func LoadEnv(env string) error {
    if env == "" {
        // get .azure/config@defaultEnvironment or err
    }
    // use godotenv to load environment's .env file,
    // optionally supporting fallback to/inclusion of any repo/ancestor .env file
}

It's not hard code to write, but any module support for azd (in Go or other languages) might help adoption.

[weikanglim]

Cleanly separated modules hasn't really been a focus of the team. In fact, it seems that the recent shift has moved us towards thinking about layers in some places.

That being said, the code to do this currently looks like something like:

azure-dev/cli/azd/cmd/util.go

Lines 117 to 127 in bfc7050

	func loadEnvironmentIfAvailable() (*environment.Environment, error) {
	azdCtx, err := azdcontext.NewAzdContext()
	if err != nil {
	return nil, err
	}
	defaultEnv, err := azdCtx.GetDefaultEnvironmentName()
	if err != nil {
	return nil, err
	}
	return environment.GetEnvironment(azdCtx, defaultEnv)
	}

With perhaps a substitution of azdContext.NewContextWithDirectory(<dir>)

[heaths]

I was actually thinking something outside of this module for use in other modules, so a log of this code may now work. Perhaps something that simply invokes azd env get-values --output json (optionally passing --environment {name}) and sets env vars similar to godotenv (doesn't override already-set env vars, though maybe that's optional).

[weikanglim]

@ellismg Want your advice here: is it wise at all for our tight partners to use our modules, or the version listed https://pkg.go.dev/github.com/azure/azure-dev@v0.0.0-20230525235853-f2aafb04f11b/cli/azd/pkg/environment?tab=versions? I'm not sure how our current module publishing works.

[ellismg]

To be 100% honest - I am very nervous about us partners taking dependencies on any exported methods from the azure-dev modules.

Fundamentally, we don't think of the entire exported surface area of these modules as public. We certainly don't intend to support the Go 1.0 promise of compatibility for all our exported members.

The artifact we ship today is the binary itself, and I view all the go code as an implementation detail of that binary. Logically, we should view everything as under an internal folder. Perhaps we should just do that at some point so folks can't accidentally break themselves into jail. We had talked about restructuring the tree at one point and doing that, but we never wanted to deal with the churn.

I think we have enough work on our plate to build a great CLI tool and a set of experiences on top of that without bringing in the need to also produce and support a set of libraries for public adoption in addition to the application itself.

[heaths]

@ellismg said,

and a set of experiences on top of that

That's why I proposed this. I agree it's not pri-1, but azd provides a great opportunity to automate workflows that are consistent with interactive use. Having a read-only module that uses azd information to facilitate that seems to fit into that vision.

I'll prototype an idea using the EXE as the API, though stabilizing the CLI and output for something like azd env get-values (--environment {name}) --output json would be helpful. (Executables are APIs, too, as long as they are treated as such.)

[heaths]

It's not waiting on my feedback.