docker image homebrew/brew

[maxwowpow]

Clarification of the purpose of the docker image homebrew/brew

Reason:
not much search results / documentation.

Summary:
Is it possible (should it be possible in theory) to install packages by brew install in a way,
that execution from the host system could be done without the docker command?

I understand it so,

• 1. there is a "base-build-system" (homebrew-core?)
• 2. that brew install compiles/installs "some files" (formula) in a private directory, independently of No.1

What I imagine could be done:

• 1. sudo docker run --rm -v "/home/linuxbrew:/home/linuxbrew" homebrew/brew brew install nano
• 2. brew installs nano in a docker-mapped linuxbrew folder, where it should be available from the host system without running a command through the docker (/usr/bin/nano link to /home/linuxbrew/<packages>/nano).

Questions:

• 1. Is this scenario typical and possible? (If yes, is there any documentation / is it relatively new and not yet documented.)
• 2. Is it untypical, but possible in theory (do compiled apps depend on "homebrew core"?). If yes, are path mappings the main challenge here?
• 3. It's completely impossible.

Trigger:
Originally, I wanted to install nano via docker .... brew install nano.
After installing it, it was nowhere to be found:
sudo docker run --rm homebrew/brew install nano the command works
sudo docker run --rm -v "/home/linuxbrew/.linuxbrew:/home/linuxbrew/.linuxbrew" homebrew/brew xxx - didn't work (should it?)
sudo docker run --rm -v "/home/linuxbrew:/home/linuxbrew" homebrew/brew nano

PS: depending on the answers and pushes in the right direction, I will attempt to test more steps.

[SMillerDev]

This is really just installing homebrew on the host with extra steps. If you run the install script it'll put the binaries in the path you suggested and you won't need docker at all.

[maxwowpow]

Thank you.
It's the question of maintenance. Having /home/linuxbrew/ with hundreds of support files / downloading via git, resolving deltas, multiple steps to oversee in an ssh session, wait, run extra env registrations, root vs user, handling updates (docker images could download/update in background). Eventually installing build dependencies. Homebrew is heavy machinery.

What would be then a good intended use for the current docker image of homebrew?

[gromgit]

I use the official Homebrew docker image to build bottles for various taps that I maintain, because it's a stable environment that can be recreated at will. I believe Homebrew CI does the same.

[SMillerDev]

The intended use is building, testing and modifying Homebrew formula and the brew program itself. You could also use it to run programs from brew and run them from the container, but generally it's better to install brew for that since that's kinda limited by the container.

[maxwowpow]

Sounds reasonable. So the idea "to exploit" the volume mapping for installing only a specific non-homebrew-dependent app there and dispose of the image was a bit too much wishful thinking.

[SMillerDev]

There's also no guarantees that what works in the pristine Ubuntu version in the container works in your OS. Homebrew as a tool knows how to manage that, but of course that wouldn't be applicable if you just move the files Homebrew installs.

[carlocab]

It sounds like what you're looking for is something like Whalebrew. (Despite the name, you don't actually need to install Homebrew to use it.)

[maxwowpow]

I actually took a look at it beforehand, and it sounds good for a "throwaway" execution of a non-essential app coming with "many" dependencies. In the context of a system-wide mini-editor (as vim/nano) it would be unfortunate not to be able to edit files, when docker is stopped.

[carlocab]

it would be unfortunate not to be able to edit files, when docker is stopped.

I suppose it would, but that's just how Docker works. Put differently, I think the answer here

Is it possible (should it be possible in theory) to install packages by brew install in a way,

that execution from the host system could be done without the docker command?

is no. That's just not possible.

When you remove your Docker container (implied by --rm), you also delete its state, so the vim or nano that you brew installed inside it is gone.

That's kind of the point of a "container": it encapsulates what you run inside of it. A container that leaves stuff on your system behind when it's gone is a pretty bad container.

[maxwowpow]

Clear point, now I understand that the question was actually about the mapping of volume(s) from the host system, so the container can "do its job (aka install a package)" and write to the persistent host storage. Then you can dispose of the image and the host-volume with configuration/user-app-packages remains intact/operable.