Moving to a new Mac: everything but Python
by Kevin Dangoor
With my new job comes a new MacBook Pro (the latest generation, very slick!). The Setup Assistant did a great job of making my new MBP just like my old one, carrying across all of my applications and settings from my latest Time Machine backup. Everything in /usr/local/bin made it. Ditto for my MacPorts stuff in /opt.
One thing that didn’t make it was the Python libraries that I had installed in the system-wide site-packages directory (/Library/Python/Version/2.5/…). The Setup Assistant is designed to not pull OS parts across when you are loading up a new machine. That makes sense, but unfortunately the Python stuff seems to fall into that category.
Perhaps the site-packages directory should be moved to /usr/local or something so that it gets copied over? A change like that would be useful for Apple to make.
Thankfully, the impact on me is pretty minimal, because I tend to do my work in virtualenvs and don’t have very many packages installed system-wide.
I think OS X should hide its system installation of Python away, for the user not to meddle with. Particularly ecause some internal OS X services use it and its twisted, and messing with this could hose those services. One should at least be forced to make a virtualenv for custom packages (e.g. make your $HOME a virtualenv), if not install a new Python from scratch. Obviously it would be nice if OS X did this out of the box, e.g. it had a secret Python installation for its internal services and once you install XCode, you get a “public” one and a virtualenv in each $HOME.
a virtualenv in $HOME would be great. I definitely agree that if Python is used for system services, having a private, “tamper resistant” system python would be a win.
+1
I had exactly the same problem after doing a system transfer from my old MacBook Pro. For most eggs(without external binary dependencies) it works just to copy them across.