Skip to content

Support binary extensions #4194

@heaths

Description

@heaths

Describe the feature or problem you’d like to solve

The new extension support for the CLI is useful. But based on vilmibm/gh-user-status I created heaths/gh-label and plan on improving it over time. However, as large as Go binaries are, the git database that is pulled is going to get large fast causing longer installs and upgrades.

Proposed solution

Some file in the repo could signal that the package is binary and instead pull binaries based on some established naming convention or information in said file from releases. If go is available, gh could perhaps run go install and check $GOBIN for gh-* binaries.

Alternatively, support Git LFS whether the hook had been installed globally or not, if possible. I've just always installed it so not sure if that's feasible.

TODO

  • install: note when a repo contains binary extension
  • list: check binary extensions for new releases
  • upgrade: check for new releases, download, update manifest
  • remove: see if it just works
  • yaml or json for manifest?
  • create: add --binary flag; seed with tooling scripts/workflow
  • local install: note and dispatch properly punted on this
  • dispatching: note binary ext, do not pass through sh
  • maintenance: clean up error handling in Upgrade
  • upgrade: separate metadata retrieval from parsing extensions
  • upgrade: consider upgrade path from "old" style to "new" style binary extensions

binary extensions on disk

  • folder alongside of git-backed extensions
  • manifest file (json or yaml?) and binary

detection of binary extension

  • absence of gh-foo file at top level of repo
  • presence of at least one release

local install

  • option 1: no local install for binary extensions
    • this would suck
  • option 2: extension author precompiles a binary, have gh extension install accept binary path
    • would symlink (fake link on windows) to path
    • manifest file indicates local
  • option 3: extension author provides shell wrapper
    • if committed and pushed, breaks binary extension detection

I think option 2 makes the most sense; going that direction.

Metadata

Metadata

Assignees

Labels

enhancementa request to improve CLI

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions