4 ms·

I'd really love to see someone make this portable to other unixes -- it'd be lovely to finally have good package management for the ~/mine/bin dirs I have on se

I'd really love to see someone make this portable to other unixes -- it'd be lovely to finally have good package management for the ~/mine/bin dirs I have on servers everywhere Amen. That could be hugely powerful.

silentbicycle 17y ago
For home directory stuff, I've found that just git can be quite sufficient for tracking and syncing dotfiles and ~/bin.
- blasdel 17y ago
  Naively syncing ~/bin only works when all your systems run the same kernel, on the same architecture, using intercompatible versions of system libraries and programming language runtimes. It also doesn't solve the package management problem at all! With homebrew, you could sync just the dotfiles and the list of installed packages, and let it take care of installing/upgrading packages on each machine. It'd be even better if it was smart enough to not shadow system packages when they are present+adequate.
  - silentbicycle 17y ago
    > That only works when all your systems run the same kernel, on the same architecture, using intercompatible versions of system libraries If dotfiles aren't compatible across OS kernels, you're doing something wrong. I keep scripts in ~/bin under VC, but with anything that needs to be compiled I just track the source and build with make (or emacs, etc.). You don't need to put everything in ~/bin in the repository! From the summary, I don't really see how the system would work transparently across OS X, Linux, and BSD. It looks like it expects git + Ruby + OS X, and I don't use the latter two. (I prefer Lua and OpenBSD, respectively, but that's me.) Also, I work with i386, amd64, and occasionally sparc, and the platform thing isn't an issue since I'm not syncing binaries.
    - blasdel 17y ago
      Yes, right now homebrew is specific to Mac OS 10.5+ -- the second paragraph of my original comment is pining for portability, so it could be used on shell accounts and beyond. A major use case is the ability for your app to be able to pull in it's own sandboxed dependencies in a crossplatform way -- so anyone can develop on their macbook independently of their system is set up, and deploy on any worthwhile server regardless of its setup. gem does a pretty damn good job of this for Ruby libraries, but it doesn't help at all for the native libraries and utilities that the gems are wrappers around :)
      - silentbicycle 17y ago
        Well, there's the Unix distro package system and another repository for Ruby gems and CPAN and LuaRocks and Hackage and ... They keep stepping on each others' toes, but I'm not sure the solution is to add even more mutually incompatible packaging systems. By their nature, they need to see the system (inc. what dependencies are available) as a whole to be really useful, and fragmenting that picture makes the situation worse for all involved. (On second reading, it looks like it's designed to try to work with CPAN et al, so that's an improvement.) It would be nice if it actually worked, but coming up with a perfectly portable global packaging system would be hard enough if it was working across platforms for one vendor, let alone the big mob that is the open source world.
mxcl 17y ago
Hi I wrote Homebrew, and this is one of my goals, I've always wanted installing from source on Linux to get package management too. I do a lot of cross platform dev, and would also love for this to work on Windows. But that may be too lofty a goal. I also added the feature where you can specify a git:// or svn:// protocol for a formula so you can easily keep up with HEAD development for your favourite project.

silentbicycle 17y ago

For home directory stuff, I've found that just git can be quite sufficient for tracking and syncing dotfiles and ~/bin.

blasdel 17y ago
Naively syncing ~/bin only works when all your systems run the same kernel, on the same architecture, using intercompatible versions of system libraries and programming language runtimes. It also doesn't solve the package management problem at all! With homebrew, you could sync just the dotfiles and the list of installed packages, and let it take care of installing/upgrading packages on each machine. It'd be even better if it was smart enough to not shadow system packages when they are present+adequate.
- silentbicycle 17y ago
  > That only works when all your systems run the same kernel, on the same architecture, using intercompatible versions of system libraries If dotfiles aren't compatible across OS kernels, you're doing something wrong. I keep scripts in ~/bin under VC, but with anything that needs to be compiled I just track the source and build with make (or emacs, etc.). You don't need to put everything in ~/bin in the repository! From the summary, I don't really see how the system would work transparently across OS X, Linux, and BSD. It looks like it expects git + Ruby + OS X, and I don't use the latter two. (I prefer Lua and OpenBSD, respectively, but that's me.) Also, I work with i386, amd64, and occasionally sparc, and the platform thing isn't an issue since I'm not syncing binaries.
  - blasdel 17y ago
    Yes, right now homebrew is specific to Mac OS 10.5+ -- the second paragraph of my original comment is pining for portability, so it could be used on shell accounts and beyond. A major use case is the ability for your app to be able to pull in it's own sandboxed dependencies in a crossplatform way -- so anyone can develop on their macbook independently of their system is set up, and deploy on any worthwhile server regardless of its setup. gem does a pretty damn good job of this for Ruby libraries, but it doesn't help at all for the native libraries and utilities that the gems are wrappers around :)
    - silentbicycle 17y ago
      Well, there's the Unix distro package system and another repository for Ruby gems and CPAN and LuaRocks and Hackage and ... They keep stepping on each others' toes, but I'm not sure the solution is to add even more mutually incompatible packaging systems. By their nature, they need to see the system (inc. what dependencies are available) as a whole to be really useful, and fragmenting that picture makes the situation worse for all involved. (On second reading, it looks like it's designed to try to work with CPAN et al, so that's an improvement.) It would be nice if it actually worked, but coming up with a perfectly portable global packaging system would be hard enough if it was working across platforms for one vendor, let alone the big mob that is the open source world.

mxcl 17y ago

Hi I wrote Homebrew, and this is one of my goals, I've always wanted installing from source on Linux to get package management too. I do a lot of cross platform dev, and would also love for this to work on Windows. But that may be too lofty a goal. I also added the feature where you can specify a git:// or svn:// protocol for a formula so you can easily keep up with HEAD development for your favourite project.