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

[John J Lee]

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.

(Not that the other stuff isn't great too, of course!-)


> I'll have to look into it some more to see if I can figure out why I did what 
> I did; I think it may actually not be necessary any more to have that 
> restriction, if in fact it ever was.

Great.


John