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 >>> <[email protected]> wrote: >>> >>>> >>>> On Jun 12, 2013, at 11:15 AM, Kurt Schwehr <[email protected]> >>>> 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 [email protected] List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
