Python ports providing GNOME bindings

[Joshua Root]

On 2010-4-16 13:19 , Jordan K. Hubbard wrote:
> 
> On Apr 15, 2010, at 5:23 PM, Ryan Schmidt wrote:
> 
>> I remain unconvinced the "bug" should be fixed. If port A depends on port X+Y and port B depends on port X+Z then what? What if X's variants +Y and +Z conflict?
> 
> Aha!  This is why I remain convinced that software should depend directly on the depot locations of its dependencies, in which case port X+Y and port X+Z can co-exist just fine on the same system.   I also suspect that it's time that we took a good, hard look at what it means to be "activated" in both the current and high-level senses of the word.  There are lots of ways of putting stuff into a process' filesystem namespace these days, only one of which involves actually making the global filesystem changes in question, the needs of MacPorts and the needs of process sandboxing may also intersect in various interesting ways.  I think there's more architecture in place in the OS to fake things out such that we *don't* have to permute all the configuration / build settings to point at all those depot locations, either, which has always been a sticking point.

I think this is definitely something that should be explored. It's more
of a research problem than a development one at the moment, in the sense
that I don't think anyone really knows how it should be done yet. (As
opposed to a lot of the work I've been doing lately, where I've known
more or less how to do it for quite a while, and it was just a matter of
finding the time and writing the code.)

I don't think depending on variants is completely infeasible, after all
ports can conflict too. At this point we're missing a syntax for
depspecs that includes variants, code to add the variants from the
depspecs to the dependencies when they are opened, a bunch of code to
detect conflicts before we start installing things (macports::upgrade in
particular needs a complete refactor to support this), some more code to
include variants in dependent checks for e.g. uninstall, and a mechanism
to distinguish between variants that are actually depended on as opposed
to requested, so existing deps are only upgraded when they need to be.

This is quite a bit of work and added complexity for something that
we're not really sold on. :-)

- Josh