I wish we'd never made these formula. Mainly because we shouldn't have some dupes and then say that we don't won't except others. But also because managing these formula is tricky. Especially when gems start installing into the Ruby cellar and that. I suggest we deprecate thusly: $ brew install ruby Homebrew recommends you use rvm (brew install rvm) We provide a ruby formula however. Install it with --force SO… you can still use the formula we provide, but we stop recommending it. Because RVM and virtualenv are better. Thoughts? Max ps yes we need rvm and virtualenv formulas. Where the hell are they even?
On 10 January 2011 02:08, Max Howell <max@methylblue.com> wrote: > I wish we'd never made these formula. Mainly because we shouldn't have some > dupes and then say that we don't won't except others. > But also because managing these formula is tricky. Especially when gems > start installing into the Ruby cellar and that. > I suggest we deprecate thusly: > $ brew install ruby > Homebrew recommends you use rvm (brew install rvm) > We provide a ruby formula however. Install it with --force > SO… you can still use the formula we provide, but we stop recommending it. > Because RVM and virtualenv are better. > Thoughts? > Max > ps yes we need rvm and virtualenv formulas. Where the hell are they even? I think Ruby formulas should be removed, or deprecated as you propose. The only problem I see is ruby installers have to learn rvm. And that the rvm formula might be tricky: where to install ? (system-wide, brew prefix, ~/.rvm)
On Mon, Jan 10, 2011 at 12:05 PM, Benoit Daloze <eregontp@gmail.com> wrote: > On 10 January 2011 02:08, Max Howell <max@methylblue.com> wrote: >> Max >> ps yes we need rvm and virtualenv formulas. Where the hell are they even? > > I think Ruby formulas should be removed, or deprecated as you propose. > The only problem I see is ruby installers have to learn rvm. > > And that the rvm formula might be tricky: where to install ? > (system-wide, brew prefix, ~/.rvm) > LOL i already explained in detail the massive problems of having an Rvm formula in a previous thread. You should use my rvm parallel installer for osx. It mimics entirely the Homebrew system-wide install script. YOU CAN GET IT AT https://gist.github.com/542746 ITS A BLATANT COPY OF MAX'S ORIGINAL INSTALL SCRIPT BUT ALL DONE FOR RVM dreamcat4 dreamcat4@gmail.com
On 10 January 2011 01:08, Max Howell <max@methylblue.com> wrote: > I wish we'd never made these formula. Mainly because we shouldn't have some > dupes and then say that we don't won't except others. I assume we'll discuss other duplicates at a later point. Subversion, for instance, is pretty pointless on 10.6 (same major version). > We provide a ruby formula however. Install it with --force > SO… you can still use the formula we provide, but we stop recommending it. Sounds good to me. I'd say we also stop trying to support packages that depend on e.g. ruby when you've installed your own version. > Because RVM and virtualenv are better. I don't know about Ruby but for Python aren't their binary packages for OSX good enough to act as a replacement? -- Mike McQuaid http://mikemcquaid.com
On Monday, 10 January 2011 at 08:41, Mike McQuaid wrote: > > I don't know about Ruby but for Python aren't their binary packages > for OSX good enough to act as a replacement? > > > > No - they install all over the place and make heavy use of the Framework's stuff. You end up with your machine in a mess. At least with rvm on Ruby its all on a set of managed prefixes. > -- > Mike McQuaid > http://mikemcquaid.com > > >
On 10/gen/2011, at 09.45, Lee Packham wrote: > On Monday, 10 January 2011 at 08:41, Mike McQuaid wrote: > >> >> I don't know about Ruby but for Python aren't their binary packages >> for OSX good enough to act as a replacement? >> > No - they install all over the place and make heavy use of the Framework's stuff. You end up with your machine in a mess. At least with rvm on Ruby its all on a set of managed prefixes. There are some bad binary packages out there (like the Qt ones that put binaries in /usr/bin, ew!), but the Python packages from python.org are perfectly fine. The 2.7 package puts the applications in /Applications/Python 2.7, the framework in /Library/Frameworks/Python.framework/Versions/2.7 (pointing the current version links there), and a few symlinks in /usr/local/bin (the actual binaries are in /Library/Frameworks/Python.framework/Versions/2.7/bin, and you can disable the symlinks in /usr/local/bin by simply unchecking a checkbox, if you prefer). "Making use of the Frameworks stuff" is a plus to me. You might feel otherwise if you're afraid of anything that doesn't look like Linux, but even then, it's anything but "a mess". CL
On Tue, Feb 22, 2011 at 3:13 PM, Camillo <camillo.lists@gmail.com> wrote: > On 10/gen/2011, at 09.45, Lee Packham wrote: > > On Monday, 10 January 2011 at 08:41, Mike McQuaid wrote: > > > I don't know about Ruby but for Python aren't their binary packages > for OSX good enough to act as a replacement? > > No - they install all over the place and make heavy use of the Framework's > stuff. You end up with your machine in a mess. At least with rvm on Ruby its > all on a set of managed prefixes. > > > There are some bad binary packages out there (like the Qt ones that put > binaries in /usr/bin, ew!), but the Python packages from python.org are > perfectly fine. The 2.7 package puts the applications > in /Applications/Python 2.7, the framework > in /Library/Frameworks/Python.framework/Versions/2.7 (pointing the current > version links there), and a few symlinks in /usr/local/bin (the actual > binaries are in /Library/Frameworks/Python.framework/Versions/2.7/bin, and > you can disable the syml inks in /usr/local/bin by simply unchecking a > checkbox, if you prefer). > "Making use of the Frameworks stuff" is a plus to me. You might feel > otherwise if you're afraid of anything that doesn't look like Linux, but > even then, it's anything but "a mess". > > CL > I call it "a mess" when it comes to uninstallation. Basically, in order to clean software installed through a .pkg off of my system, I find myself resorting to cracking the package open using Pacifist<http://www.charlessoft.com/> or Suspicious Package <http://www.mothersruin.com/software/SuspiciousPackage/> just to figure out where everything ended up. Since most package installers require admin permissions they can install things wherever they please. `brew uninstall python` is seriously a lot simpler. If OS X had something similar to the Add/Remove Programs feature in Windows, I would use a lot more packaged software. -Charlie
On 23/feb/2011, at 01.10, Charlie Sharpsteen wrote: > On Tue, Feb 22, 2011 at 3:13 PM, Camillo <camillo.lists@gmail.com> wrote: > On 10/gen/2011, at 09.45, Lee Packham wrote: >> On Monday, 10 January 2011 at 08:41, Mike McQuaid wrote: >> >>> >>> I don't know about Ruby but for Python aren't their binary packages >>> for OSX good enough to act as a replacement? >>> >> No - they install all over the place and make heavy use of the Framework's stuff. You end up with your machine in a mess. At least with rvm on Ruby its all on a set of managed prefixes. > > There are some bad binary packages out there (like the Qt ones that put binaries in /usr/bin, ew!), but the Python packages from python.org are perfectly fine. The 2.7 package puts the applications in /Applications/Python 2.7, the framework in /Library/Frameworks/Python.framework/Versions/2.7 (pointing the current version links there), and a few symlinks in /usr/local/bin (the actual binaries are in /Library/Frameworks/Python.framework/Versions/2.7/bin, and you can disable the syml inks in /usr/local/bin by simply unchecking a checkbox, if you prefer). > "Making use of the Frameworks stuff" is a plus to me. You might feel otherwise if you're afraid of anything that doesn't look like Linux, but even then, it's anything but "a mess". > > CL > > I call it "a mess" when it comes to uninstallation. Basically, in order to clean software installed through a .pkg off of my system, I find myself resorting to cracking the package open using Pacifist or Suspicious Package just to figure out where everything ended up. Since most package installers require admin permissions they can install things wherever they please. > > `brew uninstall python` is seriously a lot simpler. > > If OS X had something similar to the Add/Remove Programs feature in Windows, I would use a lot more packaged software. I agree, and I understand being distrustful of .pkg distributions in general. However, the Python guys got it right, and made it very simple to uninstall. Maybe they should include a script to do that, though. May be worth filing an issue on their bug tracker. CL
On 23 Feb 2011, at 00:10, Charlie Sharpsteen wrote: > > `brew uninstall python` is seriously a lot simpler. > > If OS X had something similar to the Add/Remove Programs feature in Windows, I would use a lot more packaged software. AppCleaner is the closest thing. Homebrew should always defer to decent upstream binary packages, we just don't have enough contributors to maintain every piece of software ever. When we have multirepo support then I hope we have all system dependencies that aren't hard dependencies of other formulae in their own repo. -- Mike McQuaid http://mikemcquaid.com
On Sat, Feb 26, 2011 at 4:22 AM, Mike McQuaid <mike@mikemcquaid.com> wrote: > > On 23 Feb 2011, at 00:10, Charlie Sharpsteen wrote: > > > > `brew uninstall python` is seriously a lot simpler. > > > > If OS X had something similar to the Add/Remove Programs feature in > Windows, I would use a lot more packaged software. > > AppCleaner is the closest thing. Homebrew should always defer to decent > upstream binary packages, we just don't have enough contributors to maintain > every piece of software ever. > > When we have multirepo support then I hope we have all system dependencies > that aren't hard dependencies of other formulae in their own repo. > > -- > Mike McQuaid > http://mikemcquaid.com > I do agree with this. If the Homebrew maintainers feel that Python and Ruby are too much trouble to keep in the main branch, I am perfectly comfortable with maintaining the formula for myself in my own personal fork. -Charlie
On 26 Feb 2011, at 20:01, Charlie Sharpsteen wrote: > I do agree with this. If the Homebrew maintainers feel that Python and Ruby are too much trouble to keep in the main branch, I am perfectly comfortable with maintaining the formula for myself in my own personal fork. Well, the hope is that multirepo support will mean you can get well-supported Python formulae and I don't get emails about it or have to bother trying to support it and everyone is happy and the unicorns and fairies will cry with joy. -- Mike McQuaid http://mikemcquaid.com
On Tue, Feb 22, 2011 at 7:10 PM, Charlie Sharpsteen <chuck@sharpsteen.net> wrote: > On Tue, Feb 22, 2011 at 3:13 PM, Camillo <camillo.lists@gmail.com> wrote: >> >> On 10/gen/2011, at 09.45, Lee Packham wrote: >> >> On Monday, 10 January 2011 at 08:41, Mike McQuaid wrote: >> >> I don't know about Ruby but for Python aren't their binary packages >> for OSX good enough to act as a replacement? >> >> No - they install all over the place and make heavy use of the Framework's >> stuff. You end up with your machine in a mess. At least with rvm on Ruby its >> all on a set of managed prefixes. >> >> There are some bad binary packages out there (like the Qt ones that put >> binaries in /usr/bin, ew!), but the Python packages from python.org are >> perfectly fine. The 2.7 package puts the applications >> in /Applications/Python 2.7, the framework >> in /Library/Frameworks/Python.framework/Versions/2.7 (pointing the current >> version links there), and a few symlinks in /usr/local/bin (the actual >> binaries are in /Library/Frameworks/Python.framework/Versions/2.7/bin, and >> you can disable the syml inks in /usr/local/bin by simply unchecking a >> checkbox, if you prefer). >> "Making use of the Frameworks stuff" is a plus to me. You might feel >> otherwise if you're afraid of anything that doesn't look like Linux, but >> even then, it's anything but "a mess". >> CL > > I call it "a mess" when it comes to uninstallation. Basically, in order to > clean software installed through a .pkg off of my system, I find myself > resorting to cracking the package open using Pacifist or Suspicious > Package just to figure out where everything ended up. Since most package > installers require admin permissions they can install things wherever they > please. > `brew uninstall python` is seriously a lot simpler. > If OS X had something similar to the Add/Remove Programs feature in Windows, > I would use a lot more packaged software. > -Charlie I think it depends. On regular apps I have no problem using the dmg. With a language distro I am very glad of brew (previously macports). Bob
On Mon, Jan 10, 2011 at 12:45 AM, Lee Packham <lpackham@leenux.org.uk>wrote: > > On Monday, 10 January 2011 at 08:41, Mike McQuaid wrote: > > > I don't know about Ruby but for Python aren't their binary packages > for OSX good enough to act as a replacement? > > No - they install all over the place and make heavy use of the Framework's > stuff. You end up with your machine in a mess. At least with rvm on Ruby its > all on a set of managed prefixes. > Exactly. The reason I don't like binary packages is that I don't want to have to crack them open with Pacifist or Suspicious Package to figure out where in the hell everything will end up in case I want to remove it later. With Homebrew, I can be pretty sure that everything will end up somewhere under $HOMEBREW_PREFIX and no-where that would require sudo rights to access.
Lots of people would be sad if we removed the Python brews from Homebrew. Let's at least get past the refactor branch and put some work into better multi-repo support. Note that RVM installs rubies, but Virtualenv *does not*. Virtualenv only provides isolated "site-packages" on an already installed Python, so the two tools aren't comparable. "Pythonbrew" is attempting to be "RVM for Python", but isn't there yet. On Sun, Jan 9, 2011 at 5:08 PM, Max Howell <max@methylblue.com> wrote: > I wish we'd never made these formula. Mainly because we shouldn't have some > dupes and then say that we don't won't except others. > But also because managing these formula is tricky. Especially when gems > start installing into the Ruby cellar and that. > I suggest we deprecate thusly: > $ brew install ruby > Homebrew recommends you use rvm (brew install rvm) > We provide a ruby formula however. Install it with --force > SO… you can still use the formula we provide, but we stop recommending it. > Because RVM and virtualenv are better. > Thoughts? > Max > ps yes we need rvm and virtualenv formulas. Where the hell are they even?
On Monday, 10 January 2011 at 01:56, Adam Vandenberg wrote: > Lots of people would be sad if we removed the Python brews from Homebrew. > Let's at least get past the refactor branch and put some work into > better multi-repo support. > > Well we wouldn't remove them. Like I said. > Note that RVM installs rubies, but Virtualenv *does not*. Virtualenv > only provides isolated "site-packages" on an already installed Python, > so the two tools aren't comparable. "Pythonbrew" is attempting to be > "RVM for Python", but isn't there yet. > > Noted.
Also, once we do get past refactor and some other things, I'm willing to maintain Python and related in a different branch. I only use the system Perl, so someone else will need to pick up supporting Ruby. On Sun, Jan 9, 2011 at 5:56 PM, Adam Vandenberg <flangy@gmail.com> wrote: > Lots of people would be sad if we removed the Python brews from Homebrew. > Let's at least get past the refactor branch and put some work into > better multi-repo support. > > Note that RVM installs rubies, but Virtualenv *does not*. Virtualenv > only provides isolated "site-packages" on an already installed Python, > so the two tools aren't comparable. "Pythonbrew" is attempting to be > "RVM for Python", but isn't there yet. > > On Sun, Jan 9, 2011 at 5:08 PM, Max Howell <max@methylblue.com> wrote: >> I wish we'd never made these formula. Mainly because we shouldn't have some >> dupes and then say that we don't won't except others. >> But also because managing these formula is tricky. Especially when gems >> start installing into the Ruby cellar and that. >> I suggest we deprecate thusly: >> $ brew install ruby >> Homebrew recommends you use rvm (brew install rvm) >> We provide a ruby formula however. Install it with --force >> SO… you can still use the formula we provide, but we stop recommending it. >> Because RVM and virtualenv are better. >> Thoughts? >> Max >> ps yes we need rvm and virtualenv formulas. Where the hell are they even? >
On Sun, Jan 9, 2011 at 5:08 PM, Max Howell <max@methylblue.com> wrote: > I wish we'd never made these formula. Mainly because we shouldn't have > some dupes and then say that we don't won't except others. > > But also because managing these formula is tricky. Especially when gems > start installing into the Ruby cellar and that. > > I suggest we deprecate thusly: > > $ brew install ruby > Homebrew recommends you use rvm (brew install rvm) > We provide a ruby formula however. Install it with --force > > SO… you can still use the formula we provide, but we stop recommending it. > Because RVM and virtualenv are better. > > Thoughts? > > Max > > ps yes we need rvm and virtualenv formulas. Where the hell are they even? > My 2 cents: - Ruby and Python are atypical duplicates. They are not just libraries or tools but entire programming languages that are major, mainstream and deployed worldwide. Not sure about Ruby (don't use it as much), but having Python 2.7 *makes a fundamental difference in which programs you can write* as there are new language features compared to Python 2.5. - rvm and virtualenv seem like great ways to manage which version of Ruby, Python provided you have multiple versions to choose from. But if we remove the brews, what is left to manage the customization and installation of a new version Ruby or Python so that it is available for virtualenv to build off of? I'm personally ok with maintaining a Python brew in my personal fork if I love it so much. But I did want to point out that Ruby and Python are so atypical that anyone pointing to them as precedent for allowing a dupe of a library or a tool like vim is grasping at straws. -Charlie
On 10 January 2011 01:56, Charlie Sharpsteen <chuck@sharpsteen.net> wrote: > I'm personally ok with maintaining a Python brew in my personal fork if I > love it so much. But I did want to point out that Ruby and Python are so > atypical that anyone pointing to them as precedent for allowing a dupe of a > library or a tool like vim is grasping at straws. If they caused as few issues as a duplicate vim I'd agree but they have a fairly hefty maintenance overhead. -- Mike McQuaid http://mikemcquaid.com
> My 2 cents: > > > - Ruby and Python are atypical duplicates. They are not just libraries or tools but entire programming languages that are major, mainstream and deployed worldwide. Not sure about Ruby (don't use it as much), but having Python 2.7 *makes a fundamental difference in which programs you can write* as there are new language features compared to Python 2.5. > - rvm and virtualenv seem like great ways to manage which version of Ruby, Python provided you have multiple versions to choose from. But if we remove the brews, what is left to manage the customization and installation of a new version Ruby or Python so that it is available for virtualenv to build off of? > > > I'm personally ok with maintaining a Python brew in my personal fork if I love it so much. But I did want to point out that Ruby and Python are so atypical that anyone pointing to them as precedent for allowing a dupe of a library or a tool like vim is grasping at straws. > > > > Being a Python noob I wasn't aware that virtualenv didn't build it's own. The whole motivation for this is that tools like RVM do it better than we can do because we're stubborn in our feature set. I don't like offering formula that have unresolved and problematic issues when there are better options. However seemingly there are no better options for python currently. I'm not even sure if RVM is better enough an option, hence this thread.
On Sun, Jan 9, 2011 at 6:02 PM, Max Howell <max@methylblue.com> wrote: > My 2 cents: > > - Ruby and Python are atypical duplicates. They are not just libraries or > tools but entire programming languages that are major, mainstream and > deployed worldwide. Not sure about Ruby (don't use it as much), but having > Python 2.7 *makes a fundamental difference in which programs you can write* > as there are new language features compared to Python 2.5. > - rvm and virtualenv seem like great ways to manage which version of Ruby, > Python provided you have multiple versions to choose from. But if we remove > the brews, what is left to manage the customization and installation of a > new version Ruby or Python so that it is available for virtualenv to build > off of? > > I'm personally ok with maintaining a Python brew in my personal fork if I > love it so much. But I did want to point out that Ruby and Python are so > atypical that anyone pointing to them as precedent for allowing a dupe of a > library or a tool like vim is grasping at straws. > > Being a Python noob I wasn't aware that virtualenv didn't build it's own. > And being a Ruby noob I wasn't aware that rvm brings it's own Ruby to the party. I also ment to compare Python 2.7 to 2.6, but a slip of the finger caused 2.5 to go out in the email. > The whole motivation for this is that tools like RVM do it better than we > can do because we're stubborn in our feature set. > > I don't like offering formula that have unresolved and problematic issues > when there are better options. However seemingly there are no better options > for python currently. > > I'm not even sure if RVM is better enough an option, hence this thread. > I think the pip/distribute issues could be solved by not installing them into the Python keg---unless there was a serious and compelling reason it was done that way in the first place. I've been meaning to make a patch and open a pull request, but have not gotten around to it. As for the packages installed by Pip, I don't know if there is a better place for them then the Python Cellar. I would suggest `/usr/local/lib/python2.7`, but not everyone installs homebrew to `/usr/local`. Seems like the npm brew may have dealt with similar issues recently---did they come up with any clever solutions? -Charlie
As a non-noob of both - here's my 2c: - rvm is awesome. In fact I don't use Ruby brew at all. I wouldn't miss it because rvm is just the way to do Ruby these days anyway. - virtualenv, although awesome, is only about library versions, not Python version. I do use it everywhere, even servers, to allow me to run multiple apps on, say, multiple versions of Django. For development it is amazing as it allows me to do the same on one machine - no DLL Hell type scenarios As noted 2.7 over 2.6/2.5 is a big jump and having the brew for that is almost essential for anyone doing, say, Django work. Especially as 2.7 is close to the py3k stuff in terms of reporting the right deprecations for developers. I don't think the pip/distribute should install outside the Python cellar - why? Because making me redo my libraries as part of the upgrade is a good idea - especially, say psycopg2 (Postgres library wrapper), as it is wise to recompile it when you recompile/update python anyway. Just my 2 cents :) Cheers, Lee Packham On 10 January 2011 02:11, Charlie Sharpsteen <chuck@sharpsteen.net> wrote: > On Sun, Jan 9, 2011 at 6:02 PM, Max Howell <max@methylblue.com> wrote: >> >> My 2 cents: >> - Ruby and Python are atypical duplicates. They are not just libraries or >> tools but entire programming languages that are major, mainstream and >> deployed worldwide. Not sure about Ruby (don't use it as much), but having >> Python 2.7 *makes a fundamental difference in which programs you can write* >> as there are new language features compared to Python 2.5. >> - rvm and virtualenv seem like great ways to manage which version of Ruby, >> Python provided you have multiple versions to choose from. But if we remove >> the brews, what is left to manage the customization and installation of a >> new version Ruby or Python so that it is available for virtualenv to build >> off of? >> I'm personally ok with maintaining a Python brew in my personal fork if I >> love it so much. But I did want to point out that Ruby and Python are so >> atypical that anyone pointing to them as precedent for allowing a dupe of a >> library or a tool like vim is grasping at straws. >> >> Being a Python noob I wasn't aware that virtualenv didn't build it's own. > > And being a Ruby noob I wasn't aware that rvm brings it's own Ruby to the > party. I also ment to compare Python 2.7 to 2.6, but a slip of the finger > caused 2.5 to go out in the email. > >> >> The whole motivation for this is that tools like RVM do it better than we >> can do because we're stubborn in our feature set. >> I don't like offering formula that have unresolved and problematic issues >> when there are better options. However seemingly there are no better options >> for python currently. >> I'm not even sure if RVM is better enough an option, hence this thread. > > I think the pip/distribute issues could be solved by not installing them > into the Python keg---unless there was a serious and compelling reason it > was done that way in the first place. I've been meaning to make a patch and > open a pull request, but have not gotten around to it. As for the packages > installed by Pip, I don't know if there is a better place for them then the > Python Cellar. I would suggest `/usr/local/lib/python2.7`, but not everyone > installs homebrew to `/usr/local`. Seems like the npm brew may have dealt > with similar issues recently---did they come up with any clever solutions? > -Charlie
On Sun, Jan 9, 2011 at 9:15 PM, Lee Packham <lpackham@leenux.org.uk> wrote: > I don't think the pip/distribute should install outside the Python > cellar - why? Because making me redo my libraries as part of the > upgrade is a good idea - especially, say psycopg2 (Postgres library > wrapper), as it is wise to recompile it when you recompile/update > python anyway. > > Just my 2 cents :) > > Cheers, > Lee Packham The problem with keeping having Pip and Distribute install their working pieces into the Python cellar is that when the user upgrades Python, all the working parts get wiped out. However, Homebrew still thinks Pip and Distribute are still installed as there are kegs in the celler---but theres only contain README files. The user then uninstalls and reinstalls Pip but gets errors about `setuptools` being missing. If you're not hip to the intricacies of Python packaging, there is no way in hell you would ever guess that this error had something to do with a package called "distribute". The end result is that after the Python 2.7.1 update the issue tracker exploded with people saying "Gaah! Pip won't install!" and there was much gnashing of teeth. Having formula that install components into the kegs of other formula just feels broken because Homebrew does not keep track of such shenanigans (and prides it's self on that point) so there is no way to go back and clean up these messes. -Charlie
Oh totally. I was caught up in the uninstall/install dance as well. I guess my suggestion is binning the distribute/pip formulae rather than the Python one. I should of actually said that rather than implied it. Cheers, Lee. On Monday, 10 January 2011 at 05:43, Charlie Sharpsteen wrote: > On Sun, Jan 9, 2011 at 9:15 PM, Lee Packham <lpackham@leenux.org.uk> wrote: > > > I don't think the pip/distribute should install outside the Python > > cellar - why? Because making me redo my libraries as part of the > > upgrade is a good idea - especially, say psycopg2 (Postgres library > > wrapper), as it is wise to recompile it when you recompile/update > > python anyway. > > > > Just my 2 cents :) > > > > Cheers, > > Lee Packham > > > > > The problem with keeping having Pip and Distribute install their working pieces into the Python cellar is that when the user upgrades Python, all the working parts get wiped out. However, Homebrew still thinks Pip and Distribute are still installed as there are kegs in the celler---but theres only contain README files. The user then uninstalls and reinstalls Pip but gets errors about `setuptools` being missing. If you're not hip to the intricacies of Python packaging, there is no way in hell you would ever guess that this error had something to do with a package called "distribute". The end result is that after the Python 2.7.1 update the issue tracker exploded with people saying "Gaah! Pip won't install!" and there was much gnashing of teeth. > > > Having formula that install components into the kegs of other formula just feels broken because Homebrew does not keep track of such shenanigans (and prides it's self on that point) so there is no way to go back and clean up these messes. > > > -Charlie > > > > >
On Sun, Jan 9, 2011 at 9:45 PM, Lee Packham <lpackham@leenux.org.uk> wrote: > Oh totally. I was caught up in the uninstall/install dance as well. I > guess my suggestion is binning the distribute/pip formulae rather than the > Python one. I should of actually said that rather than implied it. > > Cheers, > Lee > Another option may be to roll Pip and Distribute into one formula as users are pretty savvy on what to try if the `pip` command is missing. Then pip would always bring a copy of distribute with it and everything should be fine for the next Python upgrade---provided the whole show doesn't get canned before then :P -Charlie
I am basically in favor of redacting the distribute/pip formulae, as they are so easy to install "manually" on top of a Python anyway. On Sun, Jan 9, 2011 at 9:51 PM, Charlie Sharpsteen <chuck@sharpsteen.net> wrote: > On Sun, Jan 9, 2011 at 9:45 PM, Lee Packham <lpackham@leenux.org.uk> wrote: >> >> Oh totally. I was caught up in the uninstall/install dance as well. I >> guess my suggestion is binning the distribute/pip formulae rather than the >> Python one. I should of actually said that rather than implied it. >> Cheers, >> Lee > > Another option may be to roll Pip and Distribute into one formula as users > are pretty savvy on what to try if the `pip` command is missing. Then pip > would always bring a copy of distribute with it and everything should be > fine for the next Python upgrade---provided the whole show doesn't get > canned before then :P > -Charlie
On 10 January 2011 06:37, Adam Vandenberg <flangy@gmail.com> wrote: > I am basically in favor of redacting the distribute/pip formulae, as > they are so easy to install "manually" on top of a Python anyway. I agree with this. Alternatively, error out if `which python` is not the system version as if you know enough about Python to install your own version then you should know enough to be able to install distribute/pip/pythony things yourself. -- Mike McQuaid http://mikemcquaid.com