Python ports providing GNOME bindings

[Jordan K. Hubbard]

On Apr 15, 2010, at 6:19 PM, Ryan Schmidt wrote:

>> One solution is to install every port (and all of its dependencies) into its own "chroot-like" subdirectory with all of the correct dylib linkages. So each port you install might have its own personal copy of python built just the way it needs it. Since disk space is cheap, all we need to do is come up with binaries for each port+variant-combo, plus some other details here and there.
> 
> That sounds like a drastic departure from the way MacPorts works today. It sounds like a lot of work, for I'm not sure what benefit.

I beg to differ - it's not all that drastic a departure.  There is a reason that MacPorts stages through a depot today rather than just smashing everything directly into ${prefix} out of destroot, and that reason is that we always wanted the option of someday being able to "instantiate" a port in some significantly more intelligent way.   It was always clear from day one that locations like /opt/local were significantly short on real-estate, with ports needing to use various versioning conventions in their names ("tcl-8.1") to avoid colliding as things got more full in there.

Wouldn't it be nicer if you could take a depot of installed ports + some registration metadata and, from that, construct the appropriate user environment such that simply typing "emacs" in a Terminal or ssh session still worked, even though you might have 11 different versions of emacs, with various options selected, actually in the depot?   I think the user experience, and the robustness of the system as a whole, should be seen as the primary objective here, everything else being just an implementation detail for which a surprising number of solutions already exist.

> Disk space isn't necessarily *that* cheap. For example, someone I was recommending MacPorts to recently balked at the requirement to install Xcode, since he did not have enough room to do so on the small drive that came with his MacBook Air.

If MacPorts shipped binary packages, this wouldn't be an issue either.  I shouldn't need the entire MacPorts infrastructure + XCode + distribution tarballs + build scratch space just to be able to install one version of emacs on my system, either, so we have a ways to go towards *any* sort of disk space optimum here. :)

- Jordan