JuliaPackaging
Linuxbrew
Some time ago I forked Homebrew.jl and converted it to use Linuxbrew on Linux machines. The changes were not very many and relatively obvious. There is an odd failure in the tests for the moment but in practice, everything seems to be happening fine.
The repository is here: https://github.com/dpo/Linuxbrew.jl
Here are example pull requests where I convert whatever build.jl script that was there to use Linuxbrew:
- https://github.com/JuliaSmoothOptimizers/AmplNLReader.jl/pull/43
- https://github.com/JuliaSmoothOptimizers/CUTEst.jl/pull/136
It looks like it could also work to install MPI.jl: https://github.com/JuliaParallel/MPI.jl/issues/193
The obvious advantage is that Linuxbrew doesn't require root access. Some formulae will only install from bottle when Linuxbrew is installed in /home/linuxbrew, but so far I've been able to install quite a bit of stuff from bottles.
I'd like to get some feedback and know what folks think. Should it remain a separate package? Should it be merged with Homebrew.jl? Should I register it with METADATA and let people use it to gather more feedback?
@staticfloat
I'm honestly surprised the changes are so minimal. Nice work @dpo.
I have, unfortunately, not had much personal success with using Linuxbrew on my own machines. Have you been able to get it to work pretty reliably? I admit when I tried, they didn't really have much of a bottle infrastructure setup, so things may be very different now.
Just so you're aware, I have been quietly working on a setup that would allow users to build binary packages for all the major platforms that would be easily installable. For most small-to-medium binary dependencies, I think we will be able to provide a very simple, very robust installation method for everybody with very little developer pain. The basic idea will be to just package up software as tarballs and extract it on the user's computer. One of the big issues facing Julia's binary dependency distribution story today is that we have built systems on top of things like Homebrew that solve a great many problems, but for our use cases we actually don't need a lot of the complexity that they include. This causes Homebrew.jl to break just about once a week.
It is for that reason that I am hesitant to recommend that you push forward in trying to get people to use this, just because I can almost guarantee that there will be hidden sources of complexity that will rear its ugly head and cause headaches.
Now even if we do get the "ideal" system as I've described it above working, I'm not sure we'll ever be rid of packages like Homebrew.jl or Linuxbrew.jl; there are software packages like Cairo, GTK, MPI, etc... that are just so massive and so hooked into the host operating system it may be infeasible to make nicely packaged tarballs of them. We will have to see, I suppose.
Thanks for the comments @staticfloat. Linuxbrew has been very good for the few projects I've tested it on. One of them is MPI (see the MPI.jl issue I point to above). Recently, the Linuxbrew folks have really added lots of bottles. I agree that Homebrew/Linuxbrew have some complexity to them but they're also quite widely used and tested, and take care of figuring out and updating dependencies. But yes, they are moving targets to a certain extent. Surely, if more users tested it, we'd have a better idea of what needs improving.