It occurs to me that this is a breaking change. I wonder if there are scripts out there that do:

gh ext install .
go build ...

Which will start breaking. Need to think about this.

So we have two options here:

1. We just ship this and if someone complains we either say "sorry" and revert it, or say "sorry" and they hopefully make an easy change to their script
2. We only show this message in interactive mode, which is probably the most common

The advantage of not breaking is clear, the advantage of breaking is consistency. I'd probably favour consistency and if it breaks someone we can apologise. Happy for someone to disagree though.

It occurs to me that this is a breaking change. I wonder if there are scripts out there that do:

gh ext install .
go build ...

Which will start breaking. Need to think about this.

@williammartin could you talk more about why this would be breaking? Apologies if it is obvious 😅

Are you talking about if someone had a script checking if gh ext install . is successful, then it's no longer going to be successful because we're sending a message out on stderr?

Maybe we only send that message to stderr when there is a TTY?

@BagToad my bad, I actually thought this was erroring (exit non-zero), not just a warning. I don't feel strongly either way about just the message. Maybe I'd favour just having it on TTY, since realistically, people who are running it in a script probably understand what the semantics are of the command.

@williammartin, I think you're right actually. We are returning an error now and that makes us exit non-zero:

! an extension has been installed but there is no executable: expected executable file named "gh-testing-9933" in /Users/kynanware/Documents/orgs/cli/gh-testing-9933, perhaps you need to build it?

❯ echo $?
1

Ideas:

• Only return the error on TTY, so we only exit non-zero with a TTY.
  • I think this one is a bit confusing - I don't like having a different exit code whether there is a TTY or not.
• We do not print this message to stderr or return an err like originally written in the A/C. Instead, we print it to stdout when there is a TTY. Exit code remains zero for this case.

I think we should continue to exit 0 in all cases. I think most uses of cs.WarningIcon() (which is the icon for !) go to ErrOut. I'd probably be inclined to continue sending it to that stream.

Thanks @williammartin 🙇

I pushed a few commits to fix that if you could give it another review, please.

I also added tests in command_test.go to demonstrate this additional behavior.

Demo

No TTY

❯ $bingh ext install . | cat    

❯ echo $?
0

With TTY

❯ $bingh ext install .          
! an extension has been installed but there is no executable: executable file named "gh-testing-9933" in /Users/kynanware/Documents/orgs/cli/gh-testing-9933 is required to run the extension after install. Perhaps you need to build it?

❯ echo $?
0

Comments:

I saw inconsistency in the way the rest of the codebase checks if we are in a TTY before printing to stderr. I saw three different approaches:

1. Check if stderr is TTY only, then print to stderr:

2. Check if stdout is TTY only, then print to stderr:

3. Check if both stdout and stderr are TTY, then print to stderr:

With all the different options, I chose option 2 - check if stdout is TTY only, then print to stderr because there is precedent for this already in extension/command.go (see example linked in point 2 above 👆 ). Snippet of what I proposed:

Let me know if you think I should have chosen a different option, please.

After some discussion we decided that the message should only be displayed when there is a TTY.

Acceptance Criteria

Given I invoke gh without a TTY
And Given I am in a directory that doesn't have an executable for gh to call as an extension
When I run gh extension install .
Then I get no output (as is current behaviour)

~/workspace/cli/bin/gh ext install . | cat

Given I invoke gh with a TTY
And Given I am in a directory that doesn't have an executable for gh to call as an extension
When I run gh extension install .
Then I get an informative message on stderr saying "An extension has been installed but there is no executable found in this directory, perhaps you need to build it?"

➜ ~/workspace/cli/bin/gh ext install .
! an extension has been installed but there is no executable: executable file named "gh-local" in /Users/williammartin/workspace/cli-triaging/local-ext/gh-local is required to run the extension after install. Perhaps you need to build it?

This should be styled when there is a TTY and unstyled when there is not.

When I run gh extension install --help
Then I see an explanation that gh extension install . creates a symlink to an executable in the local directory regardless of whether it exists or not, and it's necessary for the user to build executables out of band if need be.

➜  gh-local ~/workspace/cli/bin/gh  extension install --help
Install a GitHub CLI extension from a GitHub or local repository.

For GitHub repositories, the repository argument can be specified in `OWNER/REPO` format or as a full repository URL.
The URL format is useful when the repository is not hosted on github.com.

For local repositories, often used while developing extensions, use `.` as the
value of the repository argument. Note the following:

- After installing an extension from a locally cloned repository, the GitHub CLI will
manage this extension as a symbolic link (or equivalent mechanism on Windows) pointing
to an executable file with the same name as the repository in the repository's root.
For example, if the repository is named `gh-foobar`, the symbolic link will point
to `gh-foobar` in the extension repository's root.
- When executing the extension, the GitHub CLI will run the executable file found
by following the symbolic link. If no executable file is found, the extension
will fail to execute.
- If the extension is precompiled, the executable file must be built manually and placed
in the repository's root.

For the list of available extensions, see <https://github.com/topics/gh-extension>.

LGTM