[Python-modules-team] Bug#620469: Bug#620496

[Clint Byrum]

Excerpts from Oxan van Leeuwen's message of Sun Apr 03 05:43:27 -0700 2011:
> # wheezy not affected as this bug blocks python-gearman from migrating
> tag 620469 + sid
> thanks
> 
> I see three solutions for this problem:
> 
> (A) Add Conflicts against each other.
>     This prevents users from installing the packages together, which normally
>     isn't needed as they provide the same functionality. It isn't optimal
>     however, as in the future it might be possible that there are programs that
>     depend on one of these libraries and that need to be co-installable.
> 
> (B) Rename the python module in one of the packages.
>     This would be the best solution, but it is a backwards-incompatible break
>     and every reverse-dependency needs to be patched to use the renamed API.
> 
> (C) Drop the __init__.py from one of the packages.
>     The two modules are actually co-installable and usable, as they don't use
>     the same namespace: python-gearman.libgearman uses gearman.libgearman,
>     while python-gearman uses just gearman. The __init__.py from
>     python-gearman can't be dropped as it imports the primary API into the
>     gearman namespace. python-gearman.libgearman seems to be functional without
>     the __init__.py, but I'm not 100% sure. Also having two packages providing
>     the same Python package is confusing.
> 

Oxan, thanks for the quick response.

I opened this issue upstream:

https://github.com/Yelp/python-gearman/issues/#issue/11

I think the way to go is to drop __init__.py from
python-gearman.libgearman, and make it depend on python-gearman, since
it is a sub-module of the gearman namespace.

I haven't been able to make gearman.libgearman work properly without
the __path__ changes, though I'm not entirely sure why as I'm sort of a
python extension novice. If anyone *can* make that work, then we don't
even need the change suggested above.

> I think the best we can do at this point is A, given the side-effects of the
> other options. I'll implement that in python-gearman (which should be enough)
> if nobody objects.

Yeah I was thinking of doing the same in the python-gearman.libgearman,
but I think since its temporary we can just leave it in python-gearman
until the necessary changes can be made for python-gearman.libgearman
to depend on python-gearman.

With the Conflicts on one side, I think we can close this bug, and open
a new wishlist bug to implement the dependency relationship.