juju / cmd Goto Github PK

This is another breaking change.

The documentation command should not be instantiated for every command supercommand. Every binary or sub-super command that implements the super command now has a documentation command. This includes things like jujud, container-agent, etc.

Instead, a documentation command should be added to the super command base as an adapter. Ideally, the documentation command should be in a sub-package, so that it can be used in isolation.

An example of this should be:

waitFor := cmd.NewSuperCommand(cmd.SuperCommandParams{
	Name:        "wait-for",
	UsagePrefix: "juju",
	Doc:         waitForDoc,
	Purpose:     "Wait for an entity to reach a specified state.",
	Documentation: documentation.NewMarkdown(),
})

If there is no documentation, it doesn't do anything. This is purely additive.

This library depends on some helper methods from juju/utils, but juju/utils in turn depends on juju/cmd. This forms a dependency loop.

I think the cleanest approach would be to copy over the helper code from juju/utils to break the loop. The methods used from juju/utils are:

• utils.NormalizePath()
• utils.Home()

This was noticed while reviewing dependencies needed to cleanly package LXD for Debian, where each library that LXD depends on must be able to build on its own with a clean set of dependencies.

See the following documentation: https://juju.is/docs/juju/juju-wait-for

It lists the following subcommands:

application - Wait for an application to reach a specified state.
help        - Show help on a command or other topic.
machine     - Wait for a machine to reach a specified state.
model       - Wait for a model to reach a specified state.
unit        - Wait for a unit to reach a specified state

Unfortunately, we don't want to show help as a subcommand, it's part of the super command type. In this case, we'd want to omit it.

The doc for juju help has an empty table for the options, e.g. see here. We should only create the table if len(options) > 0.

This is a breaking change. I'd rather we didn't call out discourse directly here. If someone wants to use something else for mapping, they have to use discourse for no other reason, than we use it.

AGPL is a pretty drastic license for a command-line library. Can we relicense with something less restrictive like BSD?

Running tests using go 1.21 results in a test failure:

	cd _build && go test -vet=off -v -p 16 github.com/juju/cmd github.com/juju/cmd/cmdtesting
=== RUN   TestPackage

----------------------------------------------------------------------
FAIL: cmd_test.go:41: CmdSuite.TestContext

cmd_test.go:42:
    c.Check(s.ctx.Context, jc.DeepEquals, context.Background())
... obtained context.todoCtx = context.todoCtx{emptyCtx:context.emptyCtx{}} ("context.TODO")
... expected context.backgroundCtx = context.backgroundCtx{emptyCtx:context.emptyCtx{}} ("context.Background")
... mismatch at top level: type mismatch context.todoCtx vs context.backgroundCtx; obtained context.todoCtx{emptyCtx:context.emptyCtx{}}; expected context.backgroundCtx{emptyCtx:context.emptyCtx{}}

OOPS: 122 passed, 1 FAILED
--- FAIL: TestPackage (0.07s)

Debian packaging has applied the following patch:

diff --git a/cmd_test.go b/cmd_test.go
index b4281f7..6df3bbb 100644
--- a/cmd_test.go
+++ b/cmd_test.go
@@ -39,7 +39,7 @@ func (s *CmdSuite) SetUpTest(c *gc.C) {
 }
 
 func (s *CmdSuite) TestContext(c *gc.C) {
-	c.Check(s.ctx.Context, jc.DeepEquals, context.Background())
+	c.Check(s.ctx.Context, jc.DeepEquals, context.TODO())
 	c.Check(s.ctx.AbsPath("/foo/bar"), gc.Equals, "/foo/bar")
 	c.Check(s.ctx.AbsPath("/foo/../bar"), gc.Equals, "/bar")
 	c.Check(s.ctx.AbsPath("foo/bar"), gc.Equals, filepath.Join(s.ctx.Dir, "foo/bar"))

A nice example of this is juju wait-for. This has 4 subcommands:

• model
• application
• unit
• machine

Instead, if we encounter a subcommand, with a set of subcommands, then just skip over the initial command and consume the sub-subcommands.

So:

• juju
  • wait-for
    • model
    • application
    • unit
    • machine

Becomes:

• juju
  • wait-for model
  • wait-for application
  • wait-for unit
  • wait-for machine