installation #9100

@paulober : have you tried adding gh completion to your shell configuration to dynamically register these?

I believe the original motivation especially because we don't distribute dmg packages is the completions depend on the version of gh installed. By evaluating it when the shell starts up, it will reflect whatever version you have installed.

Thanks for the clarification. I'll include that change in my PR if i have time. And dmgs are mainly for application packages therefore i decided to use the pkg distribution path as it's more suitable like Go, NodeJS and Python already use.

The problem with these package manages are different from user to user but the main ones i noticed and heard are:

• They often install build dependencies that quickly add up and you end up with a node_modules like approach for maybe just 2 cli tools you want to use (space requirement)
• Also these dependencies often have their own binaries which override already installed ones. Like openssl or git which override stuff provided by xcode command line tools, and as you can imagine there are many more that have this issue
• complexity if you have more tools and maybe some system configurations like zsh modifications you can end up with problems using the tools installed with a package manager. And since these PMs are way more complex than just some binaries installed, it's often overly hard to resolve some basic issues compared to the normal solution like with debs on linux, msi on windows or PKGs on macOS.
• For example brew is way to much hooked into your OS. Many people want to avoid this as you can understand
• Package manager require a network connection compared to most pkgs which you can distribute locally or in your company without the dependency on the network uplink
• System performance (different from PM to PM)
• Dependency Management Issues: Conflicts or issues with dependencies can arise, potentially breaking other software or system components.
• Version Control: Keeping track of specific versions and updates can be more challenging, especially if the package manager doesn't handle versioning well.
• Security Concerns: Installing packages from third-party repositories can pose security risks if the sources are not trusted or properly vetted.
• Consistency: Direct .pkg installations are typically more consistent with macOS's native installation methods, ensuring smoother integration and fewer unexpected issues.
• Its easier for a IT admin to distribute and allow pkgs that having to deal with the unofficial package managers

Sorry for my english, i'm not a native speaker. I hope you can understand most points if not please let me know.

Thanks for taking the time.

• Also its easier newbies/beginners to give them a pkg as they often know how to use and it's integrated by the OS vender than explaining them how to use a PM (depending that the PM works as expected.)

Also, as possibly hinted at by Paulober: users don't have HomeBrew installed by default. So to install the GitHub CLI, you first have to go install a package manager, and doing so often introduces new problems or dependencies to a user's system. A DMG avoids all of that.

As not mentioned, the GitHub documentation still to this day explicitly mentions a DMG. It takes bouncing to a few pages and then, since instructions are not present on the releases page, scrolling down to the bottom and figuring out that there is no DMG and that you need to figure out where to put gh. That should be resolved immediately if possible.

@Hughes1978 My PR adding a pkg installer has been merged already. You can find it as release artifact on GitHub for all releases since then.