Collection of potential new Installers/Checkers/Dumpers

[Okeanos]

Based on the recent discussions in #1329 (with the update to the repo via #1333) and comments in #1208 I want to collect a few thoughts on additional installers/checkers/dumpers I considered / had a very brief look at:

• TeX Live:
  • as described in Add support for TeX Live package manager (tlmgr) packages #1329 unsuitable because the default installation requires sudo; the user experience for not using sudo is not self-explanatory and difficult to explain in the context of homebrew-bundle
  • userbase / demand unknown
• JetBrains tools:
  • when relying on JetBrains Toolbox there is no way to programmatically install the actual IDEs via homebrew bundle, making extension installations impossible in a single-pass installation
  • JetBrains definitions inside of the bundle syntax should probably be IDE agnostic, e.g. using a syntax similar to jetbrains "tanvd.grazi", ide: "idea" (maybe make the IDE option an array?) and force the users to provide the expected IDE name with little to no enforcement on bundle side (loose coupling).
  • However, e.g. based on the IntelliJ IDEA, and GoLand documentation there is currently no way of: checking whether an extension is installed (install will either install or do nothing but the exit code is the same), listing currently installed extensions
• Firefox: doesn't appear to offer an interface for this but at least still has a CLI
• Google Chrome: has no CLI
• VSCodium: was already suggested in Add support for vscode extensions #1208 and should probably work similar to VSCode
  • VSCode Insiders built as differentiation between VSCode and VSCodium as well (as suggsted via Add support for vscode extensions #1208) would probably require refactoring the vscode integration … maybe via a vscode "GitHub.codespaces", insiders: true-like syntax?
• Docker Desktop extensions: may be possible when having a look at the non-marketplace documentation?
• GitHub CLI extensions: appear to be possible when looking at the docs

[MikeMcQuaid]

Sounds like, based on the above:

• TeX Live: 👎🏻
• JetBrains: 👎🏻
• Firefox: likely 👎🏻
• Google Chrome: 👎🏻
• VSCodium: should be fixed so current VSCode integration works as-is with insiders/VSCodium, don't see need for a new DSL here
• Docker: 👎🏻
• GitHub CLI: potentially 👍🏻

Closing but happy to keep discussing here.

[Okeanos]

VSCodium: should be fixed so current VSCode integration works as-is with insiders/VSCodium, don't see need for a new DSL here

Could you give a syntax example for the Brewfile explaining how you would envision this? I am likely misunderstanding this at the moment.

[MikeMcQuaid]

Could you give a syntax example for the Brewfile explaining how you would envision this? I am likely misunderstanding this at the moment.

I'm not sure yet. Are there extensions that only work on VSCode? VSCodium? VSCode Insiders? How can you find out?

[Okeanos]

I am not sure about that but I am wondering whether that is actually … relevant? I would have thought it is the users' responsibility to put in valid data and the underlying application, e.g. vscodium, would validate this. Homebrew bundle only automates the invocation after all?

[MikeMcQuaid]

@Okeanos I guess what I'm trying to understand is: what does supporting VSCodium/VSCode Insiders even look like? What breaks when using them today?

[Okeanos]

Ah, I see. For VSCodium I just had a quick look at the docs:

• The way VSCodium sources extensions is different and people may wish to configure that (inside the Brewfile) by providing the extension gallery URLs and brew bundle could then prepend them as local env variables for the specific vscodium invocation … just a thought but probably over-engineered.
• VSCodium uses codium as CLI binary instead of code that VSCode uses

For insiders / beta releases:

• VSCodium uses codium-insiders
• VSCode uses code apparently, the app bundle doesn't contain a suffixed CLI binary the way VSCodium does

[MikeMcQuaid]

Falling back to codium or codium-insiders seems appropriate if code doesn't exist (and --install-extension etc. all work the same)

[Okeanos]

Having thought about that a little:

• I am wondering how common it is to have both, i.e. stable & insiders installed (disregarding the code-suffix problem for a second)? In such a situation I would like to be able to specify for all or any of them which extensions they get.
• Having codium as a fallback to code feels a little unintuitive, i.e. like unexpected/unexplainable behavior when looking at it from a consumer running brew bundle install: Migrating between them wouldn't work as expected because extensions cannot be properly specified per IDE and the order in which things work cannot be changed either. Additionally, extensions may be installed to an IDE that is not directly apparent from the instructions in the Brewfile.

To keep things simple I would have proposed to go through all known CLI names and attempt to install the extensions for all that were found (with proper log statements). However, for codium this could pose a problem:

Since that is a rather new project, you will likely miss some extensions you know from the VS Code Marketplace.

Manual intervention at some level is required for that case. As a result I would propose to make codium an explicit setting that consumers/users can toggle themselves.

Beyond that I would, as a first step ignore the insiders version for now instead ensuring that stable works (at all).

[MikeMcQuaid]

• In such a situation I would like to be able to specify for all or any of them which extensions they get.

This introduces too much complexity.

• extensions cannot be properly specified per IDE

Why is this needed?

Manual intervention at some level is required for that case.

If manual intervention is required: it's not a good fit for homebrew-bundle.

As a result I would propose to make codium an explicit setting that consumers/users can toggle themselves.

This doesn't make sense to me. Settings like this are unintuitive and undiscoverable.

[Okeanos]

Let me rephrase:

Manual intervention at some level is required for that case.

Codium makes no promises that all VSCode extensions are available to its users (for various reasons they outline in their docs). Obviously, brew wouldn't care and simply attempt to process user input and tell the user about the problem it (codium) encountered – same with any other option/parameter that an application implemented in brew-bundle cannot process. I would expect this to be a seldomly encountered error case (but have no hands on experience).

I would specifically like to make it clear to the homebrew-bundle users what is happing for a number of reasons:

• by making codium explicitly distinct from vscode a number of interaction/discoverability/user experience problems are prevented (which would result in more support overhead here I suppose): I specified vscode, why is codium targeted? (and the reverse); I have vscode and codium installed but only want to manage extensions for vscode, how do I do that?
• failure states are more easily explained to the user when explicit inputs were chosen, giving the user a better way to correct this problem (in the brewfilew, in vscode/codium, …)
• as explained, codium is subtly different from vscode (by way of which extensions it provides, not in the CLI syntax) and if I as a user have no way of influencing what brew does … this is undefined behavior for me and I am less likely to use it
• there is a clear migration path for users who wish to switch between vscode and codium improving user experience

A "setting" (as in args or similar) is likely the wrong choice here and I agree that is less intuitive/discoverable. Having looked at the vscode-implementation I would think reusing it but making codium 'some.extension' an additional entry-point could be a feasible compromise? The overall installation invocation syntax and code flow are after all the same and it would empower users to make deliberate choices while introducing minimal code overhead.

[MikeMcQuaid]

I would expect this to be a seldomly encountered error case (but have no hands on experience).

If this isn't something you use/need: I don't think you are the best person to design or implement this, sorry.

[Okeanos]

That's fair.

I wanted to give my input as an interested third party, however, to understand what could happen (in brew bundle, as a user), explore options for things I may be needing and want to contribute, and ultimately understand what you as maintainer think is feasible/sensible. Thanks a lot for your feedback and willingness to engage with me on this level ❤️ .