[Distutils] setuptools: Missing unmanaged module warning; Failed SVN cleanup; Wrong version in .egg name

[Phillip J. Eby]

At 08:11 PM 11/1/2005 +0000, John J Lee wrote:
>On Tue, 1 Nov 2005, Phillip J. Eby wrote:
>
> > At 07:02 PM 11/1/2005 +0000, John J Lee wrote:
> >> Yes, that works -- see attached patch, verified to work on my XP SP2
> >> machine with native win32 SVN 1.2.3.
> >
> > Interestingly, I *am* able to reproduce your problem, but only with your
> > packages, though I honestly haven't tried many others.  Anyway, I'll 
> work on
> > getting a variant of your patch into 0.6a8.
>
>How odd.  FWIW, I wonder if the open source ReportLab toolkit also
>triggers this problem (since I see the same SVN working copy
>un-remove-ability with that in my day-to-day work).  I can't try on this
>box as no MSVC installed and we don't have a setuptools setup.py for it
>yet...
>
>
> >> I'm still wondering why the advertised package dependency resolution
> >> doesn't seem to work for me, though -- multi-version or not (mechanize's
> >> dependencies ClientCookie, ClientForm and pullparser are not fetched):
> >
> > Hm.  The '==dev' part is the problem.  Doing a bit of research, I see that
> > easy_install doesn't process dependencies for a package when its name and
> > version don't match what's requested on the command line.  I've 
> unfortunately
> > forgotten *why* it does this, though.  The workaround for the moment is to
> > request 'mechanize>=dev' or just 'mechanize', both of which will match any
> > 'mechanize' version.  Then the dependencies get processed.
>
>That's not a workaround for me, since as it happens what drove me to
>support setuptools was the ability to grab the SVN version + deps and set
>up sys.path.

Well, if you run 'easy_install mechanize' after first running 'easy_install 
mechanize==dev', it will keep the existing installed 'mechanize' egg, and 
then download ClientForm.  i.e., it's just a two step update.

Actually, you can do 'easy_install mechanize==dev mechanize' on one line 
and it should do the same thing.  :)

But either approach is of course just a workaround until I figure out why I 
restricted dependency processing to things that match the specified version 
requested.