Add support for TeX Live package manager (tlmgr) packages

[Okeanos]

Allow tlmgr packages to be installed, dumped, checked, updated and cleaned up.

---

First stab at this … not entirely sure it'll work as expected. Also there are a couple of sudo calls in there because a standard basictex cask installation uses paths that are not user writable by default.

There appear to be options to make this run in user mode, however, that has to be explicitly configured and should probably be handled via args in the Brewfile resulting in sudo being skipped for those calls then?

[MikeMcQuaid]

Hey @Okeanos, thanks for a(another) PR! Just to set expectations: we're definitely not going to accept this so long as it requires sudo and we may not accept it even if it can be made to not because I've never heard a request for this before.

Just wanted to give you added context before you put a tonne more time into this, sorry ❤️

[MikeMcQuaid]

I'm afraid there's no way we're going to accept this if sudo is needed here, sorry.

[Okeanos]

Hey, thanks for the early feedback. I expected as much to be honest and mainly wanted to have a stab at it (regardless) because I like the vscode integration. I'll get the syntax issues etc out of the way regardless and would, even if this get rejected by default, like some minimal feedback if it isn't too much to ask. I am specifically interested in knowing whether the places I touched (based on the vscode PR #1208 and later changes) were technically correct & complete.

Why? Mainly because outside of that PR there's pretty little documentation on the topic of integrating additional formats and there were a few interesting ideas for additional extension types.

IntellIJ for example would likely work within the acceptable bounds. I just found TeX Live more interesting to start with. Also IntelliJ and other JetBrains tools are a little tricky if the Toolbox is used to manage IntelliJ etc. – the Toolbox doesn't have CLI and putting cask: 'jetbrains-toolbox' and intellij: 'some-extension' into the same Brewfile is going to be … interesting.

[MikeMcQuaid]

Mainly because outside of that PR there's pretty little documentation on the topic of integrating additional formats and there were a few interesting ideas for additional extension types.

Yeh, I think it would be worth documenting what we'll consider/not if that'd be useful to folks like yourself?

Could also potentially figure out how to have a plugin system here.

IntellIJ for example would likely work within the acceptable bounds.

Yes, I could see that being a bit more acceptable 👍🏻. Could think about that in the docs?

[Okeanos]

Knowing what you would consider acceptable for mainstream bundle extensions would be immensely helpful. A plugin system (similar to taps) that would allow providing a wrapper for e.g. tlmgr as a third party would also be very cool because I really would like to have these packages described in my Brewfile but totally understand not accepting sudo in homebrew-bundle core.

Concerning the docs, there's a few things I'd be immediately interested in:

• some guidance on how to setup the local environment or which brew commands to invoke to get all style checks, etc. running would be very cool. I don't usually do ruby development and I have very little idea of what brew for example provides on top that I should be running locally already or how to invoke it
• standard interfaces/methods (list, outdated checks, cleanup, install), naming examples, places generally required to be touched (preferred argument order, module/class layout?)
  • I can see for naming that in checker.rb the reference to VSCode extensions is generically named extensions_to_install with no vscode prefix. Was a little confused by this when considering the implications for intellij or other tools that also use the extension nomenclature.
• deal breakers such as sudo, or other pre-requisites that cannot be satisfied on demand (and maybe how to work around them, e.g. install the cask/formula dynamically as is done for vscode?)
  • was actually surprised to see vscode being installed dynamically instead of telling the user to declare it and start again. I can totally see people removing vscode from their brewfile, forgetting about managed extensions, and then wondering why it isn't being properly removed.

[MikeMcQuaid]

Knowing what you would consider acceptable for mainstream bundle extensions would be immensely helpful.

Added in #1333

[MikeMcQuaid]

Passing on this accordingly, sorry 😭

[Okeanos]

Passing on this accordingly, sorry 😭

Hey, no worries! I did that without reaching to you first after all and when I noticed the sudo pieces, I already knew this was more than likely not gonna make it.

[colindean]

Just in case anyone returns to this, tlmgr has a user mode that enables setting a user-writable directory for packages to be installed. This would require setting TEXMFHOME and honoring that in not only brew bundle but in the consuming TeX engine. Invoking tlmgr with --usermode in Homebrew may fix this.

But I agree with Mike's additions in #1333: I don't perceive enough demand for built-in tlmgr support, even though I might use it myself.

[colindean]

Just in case anyone returns to this, tlmgr has a user mode that enables setting a user-writable directory for packages to be installed. This would require setting TEXMFHOME and honoring that in the brew bundle and the consuming TeX engine. Invoking tlmgr with --usermode in Homebrew may facilitate this.

But I agree with Mike's additions in #1333: I don't perceive enough demand presently for built-in tlmgr support, even though I might use it myself.

[MikeMcQuaid]

I don't perceive enough demand presently for built-in tlmgr support, even though I might use it myself.

Agreed 👍🏻