[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