This is for future implementation, but discussing now seems prudent.
I propose something along the lines of:
gem install homebrew
Then a way to add additional sources
brew -a source git://github.com/adamv/homebrew.git duplicates
This is the same syntax as gem. Or maybe a github convenience version
of that command:
brew -a source adamv duplicates
The above implies that formula repos by branches of the main repo, but
it may be better to force people to make them separate repositories.
The gem version installs to /usr/local by default. For more
flexibility people will need to use one of the current installation
methods. The reason for this restriction is for ease of maintenance.
But maybe a gem install isn't ideal either? What would be better though?
Max
--
Freelance mobile, desktop and web developer
http://www.methylblue.com/
Am 17.12.2009 um 15:51 schrieb Max Howell: > This is for future implementation, but discussing now seems prudent. > > I propose something along the lines of: > > gem install homebrew > > Then a way to add additional sources > > brew -a source git://github.com/adamv/homebrew.git duplicates > > This is the same syntax as gem. Or maybe a github convenience version > of that command: > > brew -a source adamv duplicates > > The above implies that formula repos by branches of the main repo, but > it may be better to force people to make them separate repositories. > > The gem version installs to /usr/local by default. For more > flexibility people will need to use one of the current installation > methods. The reason for this restriction is for ease of maintenance. > > But maybe a gem install isn't ideal either? What would be better though? I'm really not going to rain on your parade here, but I wonder if it is wise to rely on a programming language centric package management for a system package manager? I'd rather like to see some kind of bootstrapping mechanism, e.g. based on a shell script that gets the initial repository (without git) while still allowing things like `brew -a source adamv duplicates` later. Or even a dmg with a pkg to get people started quickly. Best, Jannis
> I'm really not going to rain on your parade here, but I wonder if it is wise to rely on a programming language centric package management for a system package manager? np, any kind of feedback is welcome. > I'd rather like to see some kind of bootstrapping mechanism, e.g. based on a shell script that gets the initial repository (without git) while still allowing things like `brew -a source adamv duplicates` later. Or even a dmg with a pkg to get people started quickly. The main motivation for the gem is to allow people to install homebrew easily. A dmg wouldn't be easy. An installer is less preferable to a gem seeing as there is no uninstall with Apple's installers. The README already has a method for installing homebrew that is a one line shell script: curl -L http://github.com/mxcl/homebrew/tarball/master | tar xz --strip 1 -C /usr/local After this `brew update` checks out the git repository if it isn't there. This will still work. Max
On Thu, Dec 17, 2009 at 1:16 PM, Max Howell <max@methylblue.com> wrote: >> I'm really not going to rain on your parade here, but I wonder if it is wise to rely on a programming language centric package management for a system package manager? > > np, any kind of feedback is welcome. > >> I'd rather like to see some kind of bootstrapping mechanism, e.g. based on a shell script that gets the initial repository (without git) while still allowing things like `brew -a source adamv duplicates` later. Or even a dmg with a pkg to get people started quickly. > > The main motivation for the gem is to allow people to install homebrew > easily. A dmg wouldn't be easy. An installer is less preferable to a > gem seeing as there is no uninstall with Apple's installers. If you run the installer again it should give you an option to uninstall. I know a lot of pkgs do it, and suppose that's built-in into whatever creates the pkg in the first place, though not knowing much about Xcode and the apple toolchain, I can only speculate :) -foca > The README already has a method for installing homebrew that is a one > line shell script: > > curl -L http://github.com/mxcl/homebrew/tarball/master | tar xz > --strip 1 -C /usr/local > > After this `brew update` checks out the git repository if it isn't there. > > This will still work. > > Max >
On Thu, Dec 17, 2009 at 1:04 PM, Jannis Leidel <jannis@leidel.info> wrote: > Am 17.12.2009 um 15:51 schrieb Max Howell: > >> This is for future implementation, but discussing now seems prudent. >> >> I propose something along the lines of: >> >> gem install homebrew >> >> Then a way to add additional sources >> >> brew -a source git://github.com/adamv/homebrew.git duplicates >> >> This is the same syntax as gem. Or maybe a github convenience version >> of that command: >> >> brew -a source adamv duplicates >> >> The above implies that formula repos by branches of the main repo, but >> it may be better to force people to make them separate repositories. >> >> The gem version installs to /usr/local by default. For more >> flexibility people will need to use one of the current installation >> methods. The reason for this restriction is for ease of maintenance. >> >> But maybe a gem install isn't ideal either? What would be better though? > > I'm really not going to rain on your parade here, but I wonder if it is wise to rely on a programming language centric package management for a system package manager? > > I'd rather like to see some kind of bootstrapping mechanism, e.g. based on a shell script that gets the initial repository (without git) while still allowing things like `brew -a source adamv duplicates` later. Or even a dmg with a pkg to get people started quickly. I agree, I don't see what's the benefit of having a gem (other than most homebrew users being rubyists atm and thus we more or less know the structure of a gem better than how to modify/maintain a pkg). Cheers, -foca > Best, > Jannis >
-1 for a gem. I'm quite happy with the current install method. It's fairly simple and clear what you are doing and it makes it very easy to make into a git repository and maintain local modifications. J. 2009/12/17 Nicolás Sanguinetti <hi@nicolassanguinetti.info>: > On Thu, Dec 17, 2009 at 1:04 PM, Jannis Leidel <jannis@leidel.info> wrote: >> Am 17.12.2009 um 15:51 schrieb Max Howell: >> >>> This is for future implementation, but discussing now seems prudent. >>> >>> I propose something along the lines of: >>> >>> gem install homebrew >>> >>> Then a way to add additional sources >>> >>> brew -a source git://github.com/adamv/homebrew.git duplicates >>> >>> This is the same syntax as gem. Or maybe a github convenience version >>> of that command: >>> >>> brew -a source adamv duplicates >>> >>> The above implies that formula repos by branches of the main repo, but >>> it may be better to force people to make them separate repositories. >>> >>> The gem version installs to /usr/local by default. For more >>> flexibility people will need to use one of the current installation >>> methods. The reason for this restriction is for ease of maintenance. >>> >>> But maybe a gem install isn't ideal either? What would be better though? >> >> I'm really not going to rain on your parade here, but I wonder if it is wise to rely on a programming language centric package management for a system package manager? >> >> I'd rather like to see some kind of bootstrapping mechanism, e.g. based on a shell script that gets the initial repository (without git) while still allowing things like `brew -a source adamv duplicates` later. Or even a dmg with a pkg to get people started quickly. > > I agree, I don't see what's the benefit of having a gem (other than > most homebrew users being rubyists atm and thus we more or less know > the structure of a gem better than how to modify/maintain a pkg). > > Cheers, > -foca > >> Best, >> Jannis >> >
> -1 for a gem. > > I'm quite happy with the current install method. It's fairly simple > and clear what you are doing and it makes it very easy to make into a > git repository and maintain local modifications. Yeah indeed, I don't want to make it harder to contribute. The current method is much clearer, and a gem obscures the internals.
On 17 Dec 2009, at 15:19, Max Howell wrote: >> -1 for a gem. >> >> I'm quite happy with the current install method. It's fairly simple >> and clear what you are doing and it makes it very easy to make into a >> git repository and maintain local modifications. > > Yeah indeed, I don't want to make it harder to contribute. The current > method is much clearer, and a gem obscures the internals. I think eventually it would be worth having a DMG for moderately non-technical users who want to install stuff MacPorts/Fink style. I think at the moment though if they are scared off by the current install process then Homebrew isn't ready for them yet. I'm anti-gem too. It seems bizarre to use a package management system to install another one and as one of the people who doesn't know anything about the Ruby world other than the Ruby language itself it would be just another thing to try and understand. -- Cheers, Mike Arthur http://mikearthur.co.uk
> I think eventually it would be worth having a DMG for moderately non-technical users who want to install stuff MacPorts/Fink style. I think at the moment though if they are scared off by the current install process then Homebrew isn't ready for them yet. To theorise about a DMG: it could contain a folder that you can drag and drop somewhere. But it couldn't install to /usr/local, not without a bundled script. Using a bundled script doesn't seem right. An installer could do this though. > I'm anti-gem too. It seems bizarre to use a package management system to install another one and as one of the people who doesn't know anything about the Ruby world other than the Ruby language itself it would be just another thing to try and understand. I don't see anything wrong with it personally. Homebrew is a package too. And the install instructions could be changed to the beautifully simple: gem install homebrew Possibly an installer is the best option. The gem option suited the following additional ideas that have been kicking around: 1. versioning the core and not updating it with git 2. allowing multiple formula repositories to be checked out (recursive .git directories is error prone) The formula would still be updated with Git with the gem installed Homebrew. Max
On Thu, Dec 17, 2009 at 4:46 PM, Max Howell <max@methylblue.com> wrote: >> I think eventually it would be worth having a DMG for moderately non-technical users who want to install stuff MacPorts/Fink style. I think at the moment though if they are scared off by the current install process then Homebrew isn't ready for them yet. > > To theorise about a DMG: it could contain a folder that you can drag > and drop somewhere. But it couldn't install to /usr/local, not without > a bundled script. Using a bundled script doesn't seem right. > > An installer could do this though. > >> I'm anti-gem too. It seems bizarre to use a package management system to install another one and as one of the people who doesn't know anything about the Ruby world other than the Ruby language itself it would be just another thing to try and understand. > > I don't see anything wrong with it personally. Homebrew is a package > too. And the install instructions could be changed to the beautifully > simple: > > gem install homebrew > > Possibly an installer is the best option. The gem option suited the > following additional ideas that have been kicking around: > > 1. versioning the core and not updating it with git > 2. allowing multiple formula repositories to be checked out (recursive > .git directories is error prone) > > The formula would still be updated with Git with the gem installed Homebrew. > > Max > I think gem is the way to go. It's less hassle for users (gem is included in OS X, contrarily to git). And eventually the updates to the brew utility itself will be rarer as it becomes more stable. brew will be updated with others gems as I run `gem update`, and that will be one less thing to worry about.
On Thu, Dec 17, 2009 at 3:44 PM, Pierre Riteau <pierre.riteau@gmail.com> wrote: > On Thu, Dec 17, 2009 at 4:46 PM, Max Howell <max@methylblue.com> wrote: >>> I think eventually it would be worth having a DMG for moderately non-technical users who want to install stuff MacPorts/Fink style. I think at the moment though if they are scared off by the current install process then Homebrew isn't ready for them yet. >> >> To theorise about a DMG: it could contain a folder that you can drag >> and drop somewhere. But it couldn't install to /usr/local, not without >> a bundled script. Using a bundled script doesn't seem right. >> >> An installer could do this though. >> >>> I'm anti-gem too. It seems bizarre to use a package management system to install another one and as one of the people who doesn't know anything about the Ruby world other than the Ruby language itself it would be just another thing to try and understand. >> >> I don't see anything wrong with it personally. Homebrew is a package >> too. And the install instructions could be changed to the beautifully >> simple: >> >> gem install homebrew >> >> Possibly an installer is the best option. The gem option suited the >> following additional ideas that have been kicking around: >> >> 1. versioning the core and not updating it with git >> 2. allowing multiple formula repositories to be checked out (recursive >> .git directories is error prone) >> >> The formula would still be updated with Git with the gem installed Homebrew. >> >> Max >> > > I think gem is the way to go. It's less hassle for users (gem is > included in OS X, contrarily to git). > And eventually the updates to the brew utility itself will be rarer as > it becomes more stable. > brew will be updated with others gems as I run `gem update`, and that > will be one less thing to worry about. > That's because you regularly run `gem update`. What happens with the users that actually don't use rubygems? As brew becomes more stable, more people will use it, hopefully, and not only ruby users :) So in the end you need a way to update brew from inside brew, regardless of how you got it there in the first place, which means updating a gem would mean two paths to update the code? …dunno (Just playing devil's advocate here, as long as it works as it works now, I don't really care much for a gem being available or not) -foca
2009/12/17 Nicolás Sanguinetti <hi@nicolassanguinetti.info>: > On Thu, Dec 17, 2009 at 3:44 PM, Pierre Riteau <pierre.riteau@gmail.com> wrote: >> On Thu, Dec 17, 2009 at 4:46 PM, Max Howell <max@methylblue.com> wrote: >>>> I think eventually it would be worth having a DMG for moderately non-technical users who want to install stuff MacPorts/Fink style. I think at the moment though if they are scared off by the current install process then Homebrew isn't ready for them yet. >>> >>> To theorise about a DMG: it could contain a folder that you can drag >>> and drop somewhere. But it couldn't install to /usr/local, not without >>> a bundled script. Using a bundled script doesn't seem right. >>> >>> An installer could do this though. >>> >>>> I'm anti-gem too. It seems bizarre to use a package management system to install another one and as one of the people who doesn't know anything about the Ruby world other than the Ruby language itself it would be just another thing to try and understand. >>> >>> I don't see anything wrong with it personally. Homebrew is a package >>> too. And the install instructions could be changed to the beautifully >>> simple: >>> >>> gem install homebrew >>> >>> Possibly an installer is the best option. The gem option suited the >>> following additional ideas that have been kicking around: >>> >>> 1. versioning the core and not updating it with git >>> 2. allowing multiple formula repositories to be checked out (recursive >>> .git directories is error prone) >>> >>> The formula would still be updated with Git with the gem installed Homebrew. >>> >>> Max >>> >> >> I think gem is the way to go. It's less hassle for users (gem is >> included in OS X, contrarily to git). >> And eventually the updates to the brew utility itself will be rarer as >> it becomes more stable. >> brew will be updated with others gems as I run `gem update`, and that >> will be one less thing to worry about. >> > > That's because you regularly run `gem update`. What happens with the > users that actually don't use rubygems? As brew becomes more stable, > more people will use it, hopefully, and not only ruby users :) > > So in the end you need a way to update brew from inside brew, > regardless of how you got it there in the first place, which means > updating a gem would mean two paths to update the code? …dunno > > (Just playing devil's advocate here, as long as it works as it works > now, I don't really care much for a gem being available or not) > > -foca > brew itself is not any different from any other command line tool. Does this mean that all command line tools should come with their own update mechanisms? What a mess it would be.
Am 17.12.2009 um 19:21 schrieb Pierre Riteau: > 2009/12/17 Nicolás Sanguinetti <hi@nicolassanguinetti.info>: >> On Thu, Dec 17, 2009 at 3:44 PM, Pierre Riteau <pierre.riteau@gmail.com> wrote: >>> On Thu, Dec 17, 2009 at 4:46 PM, Max Howell <max@methylblue.com> wrote: >>>>> I think eventually it would be worth having a DMG for moderately non-technical users who want to install stuff MacPorts/Fink style. I think at the moment though if they are scared off by the current install process then Homebrew isn't ready for them yet. >>>> >>>> To theorise about a DMG: it could contain a folder that you can drag >>>> and drop somewhere. But it couldn't install to /usr/local, not without >>>> a bundled script. Using a bundled script doesn't seem right. >>>> >>>> An installer could do this though. >>>> >>>>> I'm anti-gem too. It seems bizarre to use a package management system to install another one and as one of the people who doesn't know anything about the Ruby world other than the Ruby language itself it would be just another thing to try and understand. >>>> >>>> I don't see anything wrong with it personally. Homebrew is a package >>>> too. And the install instructions could be changed to the beautifully >>>> simple: >>>> >>>> gem install homebrew >>>> >>>> Possibly an installer is the best option. The gem option suited the >>>> following additional ideas that have been kicking around: >>>> >>>> 1. versioning the core and not updating it with git >>>> 2. allowing multiple formula repositories to be checked out (recursive >>>> .git directories is error prone) >>>> >>>> The formula would still be updated with Git with the gem installed Homebrew. >>>> >>>> Max >>>> >>> >>> I think gem is the way to go. It's less hassle for users (gem is >>> included in OS X, contrarily to git). >>> And eventually the updates to the brew utility itself will be rarer as >>> it becomes more stable. >>> brew will be updated with others gems as I run `gem update`, and that >>> will be one less thing to worry about. >>> >> >> That's because you regularly run `gem update`. What happens with the >> users that actually don't use rubygems? As brew becomes more stable, >> more people will use it, hopefully, and not only ruby users :) >> >> So in the end you need a way to update brew from inside brew, >> regardless of how you got it there in the first place, which means >> updating a gem would mean two paths to update the code? …dunno >> >> (Just playing devil's advocate here, as long as it works as it works >> now, I don't really care much for a gem being available or not) >> >> -foca >> > > brew itself is not any different from any other command line tool. > Does this mean that all command line tools should come with their own > update mechanisms? What a mess it would be. You're neglecting that while brew is just another command line tool, it's also a package manager which really can a distinct updating mechanism, e.g. git. Or are you suggesting to build it on top of rubgems? :) Jannis
So, my conclusions on this topic: 1. gem makes homebrew installation easier but only for people familiar with gem (which is quite a lot of people, but it's a bit exclusive) and frankly, it doesn't really solve the current installation issues, ie. to sudo-or-not. 2. gem hides the git machinary of homebrew which will make it less easy to contribute 3. gem separates homebrew up and reduces the feeling of control that has made it popular. So we won't do it. Someone else could still do it, but I'd ask that they didn't because it gives us more to worry about when we didn't actually want to have such worries. I'm not keen on a .pkg installer, but it seems the best option at this point. We'll put it on the back burner. Max
I tend to agree anyway, package managers update themselves, this is standard. Thwart standards for arbituary reasons at your peril. `brew update` can call `gem update homebrew` or whatever if we went this route. Max
It seems reasonable for people who chose to install it with the gem to have to update it with the same command. > That's because you regularly run `gem update`. What happens with the > users that actually don't use rubygems? As brew becomes more stable, > more people will use it, hopefully, and not only ruby users :) > > So in the end you need a way to update brew from inside brew, > regardless of how you got it there in the first place, which means > updating a gem would mean two paths to update the code? …dunno > > (Just playing devil's advocate here, as long as it works as it works > now, I don't really care much for a gem being available or not)
On 17 Dec 2009, at 18:15, Max Howell wrote: > It seems reasonable for people who chose to install it with the gem to > have to update it with the same command. In this case I wouldn't even offer the gem option as a primary install mechanism, I don't think we can rely on people to run gem regularly who don't know much about it. -- Cheers, Mike Arthur http://mikearthur.co.uk