How can I use homebrew (linuxbrew specifically) with Blink?

[iamnewton]

I've been combing through the docs and internet searches to see how y'all handle installing binaries on Blink Build workspaces. I'm trying to install things using linuxbrew, which installs things to /home/ which lands it into the ephemeral storage and therefore gets removed between reboots.

While I can choose a different installation directory linuxbrew advises against that for admin access reasons. Does anyone have any good work arounds for this? Has anyone tried to install linuxbrew into a separate location?

Side note: do you really have to create the bin directory to place binaries or is that just a suggestion?

[Numbski]

In this case, I think you would be okay. Just don't try to install someplace you don't have rights to, and you should be okay. Tony Shadwick

[carloscabanero]

Homebrew for Linux is designed to install all its subsystem inside /home/linuxbrew/[...]. I can imagine this is to stay out of the way of the standard Linux folders for any other distributions, as they are compiling a whole subsystem and only using glibc from your distro. Unfortunately this is incompatible with Build as a persistent package manager as Build will only save what you have in your $HOME folder. You could try to specify a different prefix, but "linuxbrew" is equivalent to recompiling another Linux distribution, and that will be heavy and inefficient.

We designed Build to offer most of the dev tools as part of our base image, Hacker Tools. Binaries and other related sub tools are usually then installed in your home folder. Ie: npx vercel, or pip install xxx, etc.... If you need other binaries within this image, we are happy to include them and figure out the best way to do so for you and keeping it updated.

$HOME/bin is the standard way to install self-compiled binaries for a local user. This has now also become quite common on self-distributed binaries on GitHub, etc... https://unix.stackexchange.com/a/36874 If you venture into compiling your own binaries for some tools, this would also be an easy way to go.

The other way we designed into Build for more complex binaries or infrastructure is to use an already made container. I have used this myself to for example, run databases like Redis, or run a Firefox GUI in the remote machine and do some debugging there.

As we are still in Beta, we are learning a lot about different use cases and how we want to approach them in the future. We developed a way to "save a container" by the user once you have installed packages in the machine so you can start from a blank container and save all along as you have a container you are happy with, etc... We are researching if we want to push it or what to do with it.

So please, let us know what tools you are missing out and most importantly, what flows you want to enable with it.

[iamnewton]

Homebrew for Linux is designed to install all its subsystem inside /home/linuxbrew/[...]. I can imagine this is to stay out of the way of the standard Linux folders for any other distributions, as they are compiling a whole subsystem and only using glibc from your distro. Unfortunately this is incompatible with Build as a persistent package manager as Build will only save what you have in your $HOME folder. You could try to specify a different prefix, but "linuxbrew" is equivalent to recompiling another Linux distribution, and that will be heavy and inefficient.

That makes sense. Do you have a recommended package manager like homebrew that includes all types of binaries? npm is great for a lot of things, but it doesn't include everything or have such an ease of addition like homebrew.

$HOME/bin is the standard way to install self-compiled binaries for a local user. This has now also become quite common on self-distributed binaries on GitHub, etc... https://unix.stackexchange.com/a/36874 If you venture into compiling your own binaries for some tools, this would also be an easy way to go.

Great!!! Good to know that this is becoming a standard.

The other way we designed into Build for more complex binaries or infrastructure is to use an already made container. I have used this myself to for example, run databases like Redis, or run a Firefox GUI in the remote machine and do some debugging there.

Do you have any examples? I'm no expert, just love using Build for developing on my iPad and trying to transition my dev setup to be more portable.

As we are still in Beta, we are learning a lot about different use cases and how we want to approach them in the future. We developed a way to "save a container" by the user once you have installed packages in the machine so you can start from a blank container and save all along as you have a container you are happy with, etc... We are researching if we want to push it or what to do with it.

This would be exactly what i'm looking for; please ship this!!!

So please, let us know what tools you are missing out and most importantly, what flows you want to enable with it.

I have a lot that I use, but most of its for bash, git or vim. Things such as bat, fzf, jq, z, tig. I don't have a complete list, but a lot of its here: https://github.com/iamnewton/dotpackages/blob/main/opt/Brewfile

[carloscabanero]

A workaround for now. For the apps that you want installed, as they all seem very straightforward, you may be able to install doing apt-get and moving the binary to $HOME/bin. Or go get (fzf) or cargo xxx (bat), they should self-install, etc... As I don't think there are crazy dependencies or additional libraries needed (and we already ship a lot). In other scenarios, maybe giving a try to home-brew with the prefix as your $HOME folder, but I have not tried it.

I'm making a note so on the next version we can make these flows a lot easier.

[iamnewton]

Thanks for all of this. On another random note, @carloscabanero I don't see any mention in the docs of how to destroy a container in build so that I can start fresh. I'm trying to install homebrew to the bin directory and want to destroy that container or anyone for that matter when I get something wrong.

[carloscabanero]

So that’s the beauty of it. Containers always start fresh, with the latest version of our image. It is only your disk that is preserved between restarts. And so you can do a rm -rf of everything in your home folder and that will serve to start anew.

Now, from my needs and hearing others, I would like to have multiple disks and decide which ones to load. Sometimes we may need different totally separated projects and I think that will help. Or maybe create one scratch disk that will be dumped And then save the containers easily as well (I think we discussed that before).

[iamnewton]

Now, from my needs and hearing others, I would like to have multiple disks and decide which ones to load. Sometimes we may need different totally separated projects and I think that will help. Or maybe create one scratch disk that will be dumped And then save the containers easily as well (I think we discussed that before).

Yeah, I also think this could be valuable from a standpoint of separating out projects in separate containers. For example, I would like to spin up a default setup image (your original container with my base set of tools) and then have separate disks for each set of projects I have, say organized by client.