7 ms·

I wouldn't recommend overwriting OSX's Python. You can install yourself from source into /usr/local, but a package manager like MacPorts or Homebrew helps a lot

I wouldn't recommend overwriting OSX's Python. You can install yourself from source into /usr/local, but a package manager like MacPorts or Homebrew helps a lot. It's a little more work up front - to install the package manager - but it pays itself back over time. Homebrew has 2.6.5 in its main branch, and 2.7 in a fork. See the notes here: http://github.com/mxcl/homebrew/blob/master/Library/Formula/python.rb http://github.com/mxcl/homebrew/blob/master/Library/Formula/... I've tried Fink, MacPorts, Rudix and Homebrew. Homebrew isn't perfect, but it's damn good.

ant5 16y ago
I'm not sure what makes Homebrew better than MacPorts. Most of their self-declared advantages -- the largest one being that they don't replicate OS-provided software -- are going to fall over as soon as the software included with Snow Leopard starts getting a bit stale. Case in point, Snow Leopard ships with Python 2.6, and now people are going to want 2.7. [Edit] I think it's also enlightening to look at this breakdown of the advertised homebrew features circa last year: http://news.ycombinator.com/item?id=872072 http://news.ycombinator.com/item?id=872072
- telemachos 16y ago
  I don't think it's perfect, but I can tell you why I have come to prefer Homebrew: 1. It's far faster. Installations and all operations take less time. 2. It's far lighter. Sure disk space is cheap, but why waste if I can avoid it? 3. It's written in a language I know well enough to contribute. (Ruby as opposed to Tcl.) And Github is Homebrew's secret weapon here. There are literally hundreds of us with forks, providing constant updates. Packages are updated far faster than Fink or MacPorts. Momentum counts. 4. They maintain a branch dedicated to providing duplicates, where people really want them. I install Vim in just this way, and they in fact provide multiple versions of Python. That said, it's not for everyone. I didn't object to MacPorts. The only option I really think is bad is overwriting the system's Python, as I said.
  - deleted 16y ago
    [deleted]
    - telemachos 16y ago
      Faster/lighter how, exactly? Faster in the simplest sense: sudo port install x takes longer to finish than brew install x. Lighter in just as straightforward a sense: same installations, less space used (fewer dependencies I suppose). The "it's Ruby" argument was entirely personal. I like to hack and help, if I can. Here I can. Rudix provides binaries, but fewer packages. The funny thing is that not that long ago, I was as skeptical as anyone. I installed Homebrew only recently when I updated two machines to Snow Leopard - mostly to prove to myself it wasn't just inertia and stubborn keeping me with MacPorts. I stayed with it because it works so well. I didn't update my post in reply to you. I often write a quick reply and then do a bunch of expanding edits. Bad habit- sorry. I haven't tried MacPorts in a few months. Maybe it's much faster. I got very, very tired of editing the Python portfile to remove the TK dependency that dragged in an entire xorg system. But I think that deep is now optional. Again, I don't have a religious attitude towards Homebrew. I tried it, and I'm very happy with it for now.
  - ant5 16y ago
    Replying again since you updated in response to my questions =) 1. It's far faster. Installations and all operations take less time. That hasn't been my experience, but have you checked the latest release? It switched the local installation information to sqlite, which seems to make things mighty fast. 2. It's far lighter. Sure disk space is cheap, but why waste if I can avoid it? Because the "we won't replicate dependencies" thing won't survive another full OS X release cycle. Snow Leopard was a rushed release cycle that brought a quick refresh to the OS-supplied components, but it was a once-off and it's not going to happen again soon, especially given the focus on iOS. 3. ... And Github is Homebrew's secret weapon here. There are literally hundreds of us with forks, providing constant updates. Packages are updated far faster than Fink or MacPorts. Momentum counts. That doesn't seem to match reality. Take the current case; MacPorts: * Has been tracking Python2.7 releases since its alpha release 5 months ago. * Has years worths of institutional knowledge regarding patching Python to actually fully function (see the portfile here: http://trac.macports.org/browser/trunk/dports/lang/python27/Portfile http://trac.macports.org/browser/trunk/dports/lang/python27/...). * Provides ports for python 2.4, 2.5, 2.6, 2.7 and 3.1 (all of which are not always backwards compatible) Homebrew is tracking only Python2.6, didn't have any Python2.7 submissions until yesterday, and hasn't integrated the change into mainline. When they -do- integrate the change into mainline, everybody is going to have to deal with the headaches that invariably occur across minor releases of Python[1], rather than tracking the multiple versions they require, because homebrew has a naively simple and ultimately flawed policy of "only one version". Most of the complexity in MacPorts and Fink is a direct result of understanding the complexity of the problem space over a decade. Homebrew will become just as complex as time reveals the necessity of many of these compromises. [1] As an example, http://twistedmatrix.com/trac/query?status=closed&group=resolution&milestone=Python-2.7 http://twistedmatrix.com/trac/query?status=closed&group=...
jdbeast00 16y ago
i am a new mac user (and new to *nix in general). i was trying to get mapnik with postgres working on my mac yesterday and it took me 5 hours to get macports / mapnik setup, and after most of my day was done it turns out that ImageMagick via macports and snow leopard don't mix. (Finally I tried downloading the binary for ImageMagick but then macports doesn't recognize it..) Very frustrating. Is there really nothing better, or am i just too much of a noob? What is the reason for making me build it instead of doing soemthing like apt-get on ubuntu?
- telemachos 16y ago
  Short answer: it's not you; it's Apple, mostly. There is nothing for OSX as good as the APT tools. Apple provides a good selection of nix tools, but it cripples some, rarely updates them and has zero investment in a larger tool-set for dealing with them. All the community solutions are imperfect. What MacPort "sees" is what's in /opt/local with its tools. I'll bet the binary you got installed ImageMagick into /usr/local. (That's pretty common.) Welcome to *nix package management, sadly.
  - JadeNB 16y ago
    > What MacPort "sees" is what's in /opt/local with its tools. I'll bet the binary you got installed ImageMagick into /usr/local. It's actually worse than this; MacPorts maintains its own idea of what's installed, and, while you can put your files in its directories, that won't fool it into believing that ImageMagick is installed if it hasn't done it itself. (People have asked MacPorts for ways to work around this—to avoid installing all the X libraries again just to use an X application, for example—but, as near as I can tell, this is a design decision.) Also, it's 'true enough', but not always true, that MacPorts looks in /opt/local. For example, I'm finicky about having one easily backed-up directory for everything that I install, so mine is in /Users/Shared/Applications/Utilities/MacPorts (much easier to type, no? :-) ).
    - ant5 16y ago
      > ... near as I can tell, this is a design decision. Yes. A very long time ago, MacPorts relied on file dependencies; if a library was there, it was used. The problem that emerged was that these dependencies often broken. Sometimes Apple shipped a broken update, sometimes users installed broken software. This would cause MacPorts to break. If Apple shipped a broken update (eg, openssl headers that didn't match the openssl library), MacPorts had to switch to their own openssl package in order to be able to keep building software. If users installed broken, too-old, or otherwise non-suitable packages, the MacPorts developers had to help debug their rather random systems to figure out the problem. When you couple this with OS-shipped dependencies that go stale, you necessarily see your dependency tree begin relying on internal dependencies for almost everything, and due to all the software deployed using those dependencies, you can't cull them from the tree. So instead you wind up maintaining a controlled, parallel universe. It's foolish to think this won't happen with Homebrew, too.
nuxi 16y ago
But you don't overwrite OSX's python, the new version is installed side-by-side. The installation also creates links to the new version into /usr/local/bin, so that it doesn't mess up the system's python. Never had any trouble with this.

ant5 16y ago

I'm not sure what makes Homebrew better than MacPorts. Most of their self-declared advantages -- the largest one being that they don't replicate OS-provided software -- are going to fall over as soon as the software included with Snow Leopard starts getting a bit stale. Case in point, Snow Leopard ships with Python 2.6, and now people are going to want 2.7. [Edit] I think it's also enlightening to look at this breakdown of the advertised homebrew features circa last year: http://news.ycombinator.com/item?id=872072 http://news.ycombinator.com/item?id=872072

telemachos 16y ago
I don't think it's perfect, but I can tell you why I have come to prefer Homebrew: 1. It's far faster. Installations and all operations take less time. 2. It's far lighter. Sure disk space is cheap, but why waste if I can avoid it? 3. It's written in a language I know well enough to contribute. (Ruby as opposed to Tcl.) And Github is Homebrew's secret weapon here. There are literally hundreds of us with forks, providing constant updates. Packages are updated far faster than Fink or MacPorts. Momentum counts. 4. They maintain a branch dedicated to providing duplicates, where people really want them. I install Vim in just this way, and they in fact provide multiple versions of Python. That said, it's not for everyone. I didn't object to MacPorts. The only option I really think is bad is overwriting the system's Python, as I said.
- deleted 16y ago
  [deleted]
  - telemachos 16y ago
    Faster/lighter how, exactly? Faster in the simplest sense: sudo port install x takes longer to finish than brew install x. Lighter in just as straightforward a sense: same installations, less space used (fewer dependencies I suppose). The "it's Ruby" argument was entirely personal. I like to hack and help, if I can. Here I can. Rudix provides binaries, but fewer packages. The funny thing is that not that long ago, I was as skeptical as anyone. I installed Homebrew only recently when I updated two machines to Snow Leopard - mostly to prove to myself it wasn't just inertia and stubborn keeping me with MacPorts. I stayed with it because it works so well. I didn't update my post in reply to you. I often write a quick reply and then do a bunch of expanding edits. Bad habit- sorry. I haven't tried MacPorts in a few months. Maybe it's much faster. I got very, very tired of editing the Python portfile to remove the TK dependency that dragged in an entire xorg system. But I think that deep is now optional. Again, I don't have a religious attitude towards Homebrew. I tried it, and I'm very happy with it for now.
- ant5 16y ago
  Replying again since you updated in response to my questions =) 1. It's far faster. Installations and all operations take less time. That hasn't been my experience, but have you checked the latest release? It switched the local installation information to sqlite, which seems to make things mighty fast. 2. It's far lighter. Sure disk space is cheap, but why waste if I can avoid it? Because the "we won't replicate dependencies" thing won't survive another full OS X release cycle. Snow Leopard was a rushed release cycle that brought a quick refresh to the OS-supplied components, but it was a once-off and it's not going to happen again soon, especially given the focus on iOS. 3. ... And Github is Homebrew's secret weapon here. There are literally hundreds of us with forks, providing constant updates. Packages are updated far faster than Fink or MacPorts. Momentum counts. That doesn't seem to match reality. Take the current case; MacPorts: * Has been tracking Python2.7 releases since its alpha release 5 months ago. * Has years worths of institutional knowledge regarding patching Python to actually fully function (see the portfile here: http://trac.macports.org/browser/trunk/dports/lang/python27/Portfile http://trac.macports.org/browser/trunk/dports/lang/python27/...). * Provides ports for python 2.4, 2.5, 2.6, 2.7 and 3.1 (all of which are not always backwards compatible) Homebrew is tracking only Python2.6, didn't have any Python2.7 submissions until yesterday, and hasn't integrated the change into mainline. When they -do- integrate the change into mainline, everybody is going to have to deal with the headaches that invariably occur across minor releases of Python[1], rather than tracking the multiple versions they require, because homebrew has a naively simple and ultimately flawed policy of "only one version". Most of the complexity in MacPorts and Fink is a direct result of understanding the complexity of the problem space over a decade. Homebrew will become just as complex as time reveals the necessity of many of these compromises. [1] As an example, http://twistedmatrix.com/trac/query?status=closed&group=resolution&milestone=Python-2.7 http://twistedmatrix.com/trac/query?status=closed&group=...

jdbeast00 16y ago

i am a new mac user (and new to *nix in general). i was trying to get mapnik with postgres working on my mac yesterday and it took me 5 hours to get macports / mapnik setup, and after most of my day was done it turns out that ImageMagick via macports and snow leopard don't mix. (Finally I tried downloading the binary for ImageMagick but then macports doesn't recognize it..) Very frustrating. Is there really nothing better, or am i just too much of a noob? What is the reason for making me build it instead of doing soemthing like apt-get on ubuntu?

telemachos 16y ago
Short answer: it's not you; it's Apple, mostly. There is nothing for OSX as good as the APT tools. Apple provides a good selection of nix tools, but it cripples some, rarely updates them and has zero investment in a larger tool-set for dealing with them. All the community solutions are imperfect. What MacPort "sees" is what's in /opt/local with its tools. I'll bet the binary you got installed ImageMagick into /usr/local. (That's pretty common.) Welcome to *nix package management, sadly.
- JadeNB 16y ago
  > What MacPort "sees" is what's in /opt/local with its tools. I'll bet the binary you got installed ImageMagick into /usr/local. It's actually worse than this; MacPorts maintains its own idea of what's installed, and, while you can put your files in its directories, that won't fool it into believing that ImageMagick is installed if it hasn't done it itself. (People have asked MacPorts for ways to work around this—to avoid installing all the X libraries again just to use an X application, for example—but, as near as I can tell, this is a design decision.) Also, it's 'true enough', but not always true, that MacPorts looks in /opt/local. For example, I'm finicky about having one easily backed-up directory for everything that I install, so mine is in /Users/Shared/Applications/Utilities/MacPorts (much easier to type, no? :-) ).
  - ant5 16y ago
    > ... near as I can tell, this is a design decision. Yes. A very long time ago, MacPorts relied on file dependencies; if a library was there, it was used. The problem that emerged was that these dependencies often broken. Sometimes Apple shipped a broken update, sometimes users installed broken software. This would cause MacPorts to break. If Apple shipped a broken update (eg, openssl headers that didn't match the openssl library), MacPorts had to switch to their own openssl package in order to be able to keep building software. If users installed broken, too-old, or otherwise non-suitable packages, the MacPorts developers had to help debug their rather random systems to figure out the problem. When you couple this with OS-shipped dependencies that go stale, you necessarily see your dependency tree begin relying on internal dependencies for almost everything, and due to all the software deployed using those dependencies, you can't cull them from the tree. So instead you wind up maintaining a controlled, parallel universe. It's foolish to think this won't happen with Homebrew, too.

nuxi 16y ago

But you don't overwrite OSX's python, the new version is installed side-by-side. The installation also creates links to the new version into /usr/local/bin, so that it doesn't mess up the system's python. Never had any trouble with this.