flox list --manifest

[zmitchell]

Acceptance Criteria

• Add a check that only allows EDITOR to be called when in an interactive context e.g. via Dialog::can_prompt.
• Rename the option to --manifest. Keep supporting the --config option but don't list it and change all references to it to the --manifest option

Original issue

Observations

• There are use cases which require editing the manifest non-interactively.
• One method of non-interactive editing is to set EDITOR to a script since flox edit complains if EDITOR isn't set.
• #236 allows flox edit to update the manifest with contents provided on stdin, which would be useful in a non-interactive context
• #236 removes a check that prevents flox edit from being called interactively in a non-interactive context
• There is currently no flox command that prints the manifest contents
• There's no way to predict whether EDITOR will hang because flox doesn't know beforehand whether EDITOR is an interactive editor or a script.

Problem

• The current (feature-flagged) flox edit makes the trade-off of allowing a user to call flox edit interactively in a non-interactive context (which is a user mistake, and will hang forever) in order to allow using an EDITOR-script to update the manifest in a non-interactive context.
• This tradeoff could be eliminated by simply adding a command to print the current manifest contents so that a manifest could be edited non-interactively via flox <new cmd> | <some script> | flox edit -f -.
• Without a way to get the current manifest contents, there's no way for a script (note: not EDITOR set to a script, just a script) to get the current manifest contents so that they can be processed and passed to flox edit -f - to be read from stdin.

Approach

• Add a flox print or flox manifest command that simply prints the current contents of the manifest.
  • The actual implementation would be as simple as PathEnvironment::manifest_path -> std::fs::read_to_string -> println!.
• Add a check that only allows EDITOR to be called when in an interactive context e.g. via Dialog::can_prompt.

[ghudgins]

lets just add something without listing it in help for now. we have some plans to fully consider import, export, copy, etc coming soon and tweak the spec accordingly

[ghudgins]

@zmitchell - why do we need a command for this, couldn't someone wanting to interactive programmatically with the manifest use cat manifest.toml?

[zmitchell]

That would work for project environments, where a user is reasonably expected to know where their manifest lives. For managed or remote environments I don't think we have that same expectation.

[ghudgins]

we now have flox list -c can we close this?

[mkenigs]

We probably still need to do:

* Add a check that only allows `EDITOR` to be called when in an interactive context e.g. via `Dialog::can_prompt`.

(would take 5 min)