[Request] add tools and shell integration to Homebrew

[andrewcrook]

Would be nice to have the option to install via Homebrew on macOS and perhaps other package managers on other OSs In order to keep these updated etc

[dvershinin]

+1 for package managers on other OS. Because iTerm2 is more likely to be used against a remote non-OSX system (e.g. Linux).

And to be well accepted for packagers, it also needs:

• more documentation (either simply individual .md for each program, so that man pages can be generated from those)
• separate GitHub repo and thus versioning

A separate repo, seriously. Because the standard approach there is building packages off an official tarball. Otherwise, there is a need to download a 4GB(!) tarball to build the package for a handful of bash scripts...

[dvershinin]

If someone is interested, I've built packages for RHEL 7, 8:

• iterm2-shell-integration-bash (.spec here) - installs shell integration to profile.d (thus, should work for all users)
• iterm2-utilities (.spec here)

Subject to the free usage of the GetPageSpeed RPM repository.

[gnachman]

I have no idea how to do this but if someone wants to take this on I'll be glad to help however I can.

[dvershinin]

@gnachman would be great if you could create another repo, e.g. gnachman/iterm2-server-integration and move both the source/utilities and source/shell_integration from here to the newly created repo.

Then tag a stable release version, e.g. v0.0.1 in the iterm2-server-integration repo.

[gnachman]

@gnachman would be great if you could create another repo, e.g. gnachman/iterm2-server-integration and move both the source/utilities and source/shell_integration from here to the newly created repo.

Then tag a stable release version, e.g. v0.0.1 in the iterm2-server-integration repo.

Why does it need to be in its own repo? I could certainly do that but in my experience a proliferation of repos eventually causes a lot of pain.

[dvershinin]

Sorry if I wasn't clear enough.

Packages are created from official source tarballs.

If things stay in this single repo

• It means that a package's source RPM (e.g. for CentOS), is very bloated, 4GB. The process of downloading and packaging those few scripts for utilities (which are less than a megabyte's worth) into an RPM is time-consuming and unnecessary bandwidth due to having to download the entire source tarball
• What defines a release version for the shell/utility package? When you make an update on those scripts/integration and we want a new version released... We would have to resort to git snapshots, which makes automatic repackaging virtually impossible or very hard to accomplish. Because these utilities have no clear version.

If things are put in a separate repo

• Packagers have a single-source reference to create the package from, with just what they need
• A release version can be defined through standard mechanisms, e.g. looking at GitHub releases, and with appropriate tools, automatic packaging is possible when you tag a new version there.
• As an added bonus, users can file tickets specifically against these utilities/integration. E.g. I do notice a somewhat sluggish typing behavior with the shell integration. It probably makes little "sense" to file that issue in gnachman/iterm2-website

[gnachman]

Thanks for clarifying. Considering I also need this code in the main iTerm2 repo this makes a lot of sense. I've created this repo:

https://github.com/gnachman/iTerm2-shell-integration

I don't think we need a tagging scheme because this is continuously deployed. Feel free to build off the main branch whenever it changes.