refactor!: de-zarfify maru-runner

[Racer159]

Description

This PR removes Zarf as a dependency of Maru, and proposes the following breaking changes to the library API surface:

1. Creating a simple registration system for ./ prefixed apps
2. Not reaching into os.Env within library code (i.e. when processing RUN_<VAR>)

This also proposes the following feature breaking changes:

1. Drop support for files.

Related Issue

Fixes #23
Fixes #60

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[Racer159]

still wip, there is some breakage with files and this still depends on message

[UncleGedd]

Re: new deps. Looking at defenseunicorns/pkg, I see helpers but not exec or variables . Where are these deps coming from?

^ referring to the following entries from the go.mod:

	github.com/defenseunicorns/pkg/exec v0.0.0-20240514195347-a77ce380de8c
	github.com/defenseunicorns/pkg/helpers v1.1.3-0.20240514195347-a77ce380de8c
	github.com/defenseunicorns/pkg/variables v0.0.0-20240514195347-a77ce380de8c

EDIT: nvm I found them defenseunicorns/pkg#80

[UncleGedd]

I understand the registration system and removal of config.CmdPrefix, but I don't get the second breaking change: "Not reaching into os.Env within library code". Can we get more context there?

[Racer159]

I understand the registration system and removal of config.CmdPrefix, but I don't get the second breaking change: "Not reaching into os.Env within library code". Can we get more context there?

This is a breakage for any users of Maru as a library - (which @ericwyles pointed out I was misinformed about uds-cli's integration of Maru) - basically we only pull the os.Env in the cmd package now so if you use Run directly you'd have to inject those env vars as set variables yourself.

We should discuss but I also think that uds-cli should switch from vendoring Maru to calling Run so that it can have more control and we don't need to have global config vars for all of the configuration.

[UncleGedd]

We should discuss but I also think that uds-cli should switch from vendoring Maru to calling Run so that it can have more control and we don't need to have global config vars for all of the configuration.

👍 I'm good with that

[Racer159]

We should discuss but I also think that uds-cli should switch from vendoring Maru to calling Run so that it can have more control and we don't need to have global config vars for all of the configuration.

👍 I'm good with that

After discussing with @ericwyles yesterday I have changed my opinion back - we could do things to make it easier to run from library code (i.e. centralizing command flags) but they likely aren't necessary near term for what UDS CLI actually needs (likely a config var thing would work and we still should be able to control it well enough that vendoring apps like zarf / uds-cli don't step on each other in the globals)

[Racer159]

Thinking of leaving prompt in for now (as dead code we can either cleanup or implement later) - I implemented generics though for the Zarf specific variable values that are carried through.