[Distutils] setuptools include_package_data ignore data under a 'package'?

Phillip J. Eby pje at telecommunity.com
Wed Jan 25 05:14:55 CET 2006


At 06:14 PM 1/24/2006 -0800, Trent Mick wrote:
>[Phillip J. Eby wrote]
> > Yeah, this is actually on my list, just haven't got 'round to it yet.  For
> > systems that include their control data in-band (as files/dirs in the
> > project area) it's pretty easy, but my impression was that most things
> > besides CVS and Subversion don't do this.  It would help if folks using 
> the
> > other tools could give some idea of how you go about finding tracked files
> > using them, so I could get a better idea of how the extension API 
> should work.
>
>If I understand what you are asking here, you get the list of Perforce
>files in the current client view (kinda the equivalent of an SVN working
>copy) with the "p4 have ./..." command:
>[snip]

Actually, I was looking more for how to identify this sort of thing without 
searching the system to see where the executables are, and then trying to 
figure out if 'p4' is really Perforce or not.  Subversion and CVS are 
pretty unambiguous to detect; I was hoping for something equally 
unambiguous for other systems.  Certainly, to implement revision control 
support in the actual setuptools core code, it needs to be doable without 
requiring anything outside the standard library.

Plugins to support revision control don't have this issue, and they're 
needed only by the original developer making source distributions from 
checkouts.  So if there's a plugin to implement say, Perforce support, it's 
okay for that plugin to have library dependencies or require special 
configuration files or whatever, so long as they can be found via 
environment variables or via distutils configuration options.

I think what I should probably do at this point is just refactor the 
current file finder to be a plugin itself, and publish the API.  Then, I 
guess people wanting to implement support for other systems can tell me if 
the API is lacking something they need.  That'll probably be easier than 
trying to design a plugin API from scratch.



More information about the Distutils-SIG mailing list