On Jun 13, 2013, at 10:09 PM, Alexander Hansen wrote:

> On 6/12/13 6:27 PM, Alexander Hansen wrote:
>> On 6/12/13 6:19 PM, Kurt Schwehr wrote:
>>> Yup.  Suggestions on a solution?
>>> 
>>> On Jun 12, 2013, at 6:13 PM, Daniel Johnson
>>> <daniel.johnso...@gmail.com> wrote:
>>> 
>>>> 
>>>> On Jun 12, 2013, at 11:15 AM, Kurt Schwehr <kurtschw...@yahoo.com>
>>>> wrote:
>>>> 
>>>>> The author of distribute merged distribute back into setuptools 0.7
>>>>> and took over as lead of setuptools.  Please convert python packages
>>>>> that use distribute back to setuptools.
>>>>> 
>>>>> Just committed setuptools 0.7.2 to 10.[78] and 10.[56].
>>>>> 
>>>>> https://pypi.python.org/pypi/setuptools/0.7.2#id3
>>>>> https://bitbucket.org/pypa/setuptools/src/tip/docs/merge.txt
>>>> 
>>>> This is causing a bit of a dependency problem. Some packages Depend
>>>> on distribute-py rather than just BuildDepend, such as my
>>>> modernize-py. Since setuptools and distribute are mutually exclusive,
>>>> I now can't install setuptools at all without removing modernize
>>>> first. I can update modernize to use setuptools but the
>>>> already-installed version prevents the update from happening since
>>>> distribute has to be uninstalled first, which causes a dependency loop.
>>>> 
>>>> Daniel
>>>> 
>>> 
>>> 
>> 
>> If the new setuptools is drop-in compatible with our current distribute,
>> then how about making a dummy upgrade distribute which Depends on
>> setuptools (>= 0.7.2)?
>> 
> 
> I found something which looks like it works.  The gist is:
> 
> 1) Make distribute a real package again but have it really be 
> setuptools-0.7.2.  This has the following:
> Conflicts: setuptools-py%type_pkg[python] (<< 0.7.2-3)
> Replaces: setuptools-py%type_pkg[python]
> Provides: setuptools-py%type_pkg[python]
> 
> The unversioned Replaces: will allow it to replace setuptools (>= 0.7.2-3) 
> without removing the package entry, and the Provides: keeps current users of 
> setuptools (via the prior Provides from the old distribute) happy.
> 
> 2) Do the following in setuptools:
> 
> Conflicts: distribute-py%type_pkg[python] (<< 0.7.2-3)
> Replaces: distribute-py%type_pkg[python]
> Provides: distribute-py%type_pkg[python]
> 
> This allows folks who update distribute automatically to get setuptools 
> (under the distribute label) without any nasty dependency hell.
> 
> Then, if setuptools is updated and installed, it overwrites the overlapping 
> files from distribute with identical ones, but does _not_ remove the 
> distribute package (since there is no Conflict), so packages with 
> dependencies on it are happy.
> 
> It's not a complete solution, probably, but at least we can tell users to 
> update distribute first.
> 
> .infos attached.

This has been sitting on my TODO list, but now it looks like there is a 
setuptools-tng-py*? I can hold off on upgrading my .info files if this is still 
being worked out, but if not...

Kurt: looks like nose-py is still depending on the non-tng setuptools in the 
10.7 tree. (I was being lazy and trying a 'fink remove setuptools-py*' to see 
what dependencies broke. Haven't checked for others.)

-- 
Charles Lepple
clepple@gmail




------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to