setuptools include_package_data ignore data under a 'package'?
I've been having some strange issues when trying to get include_package_data to actually include package data, when said data is under a module. Though it seems to behave unpredictably. For example, several people have installed Pylons and its been missing pylons/media/style/orange.css (a package file), though I haven't had this happen myself. However, when I make a new template project, then bundle it into a distribution and unpack it (to see what setuptools thought was package data). It's missing several directories. Easy way to reproduce: paster create --template=pylons test cd test python setup.py sdist cd dist tar xzvf test-0.0.0dev.tar.gz Then compare: ls test-0.0.0dev/test/ To ../test/ The new one is missing the docs, public, templates directories which are package data directories containing content. If these aren't included on purpose, where can I get more information on exactly what include_package_data=True does actually include? BTW, I'm using setuptools 0.6a9 Thanks, Ben
The new one is missing the docs, public, templates directories which are package data directories containing content. If these aren't included on purpose, where can I get more information on exactly what include_package_data=True does actually include?
BTW, I'm using setuptools 0.6a9
Nevermind, I already see this was due to me not having checked in the project to a version control system or registering all the files manually in MANIFEST.in. Any plans to support darcs? - Ben
On Jan 24, 2006, at 4:33 PM, bbangert@groovie.org wrote:
The new one is missing the docs, public, templates directories which are package data directories containing content. If these aren't included on purpose, where can I get more information on exactly what include_package_data=True does actually include?
BTW, I'm using setuptools 0.6a9
Nevermind, I already see this was due to me not having checked in the project to a version control system or registering all the files manually in MANIFEST.in.
Any plans to support darcs?
If you want darcs (hg, svk, perforce, ...) support, I'm sure it'd get added if you wrote a patch :) Perhaps setuptools should support manifest generating hooks via an entry point? -bob
At 05:08 PM 1/24/2006 -0800, Bob Ippolito wrote:
On Jan 24, 2006, at 4:33 PM, bbangert@groovie.org wrote:
The new one is missing the docs, public, templates directories which are package data directories containing content. If these aren't included on purpose, where can I get more information on exactly what include_package_data=True does actually include?
BTW, I'm using setuptools 0.6a9
Nevermind, I already see this was due to me not having checked in the project to a version control system or registering all the files manually in MANIFEST.in.
Any plans to support darcs?
If you want darcs (hg, svk, perforce, ...) support, I'm sure it'd get added if you wrote a patch :)
Perhaps setuptools should support manifest generating hooks via an entry point?
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.
[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: $ p4 help have have -- List revisions last synced p4 have [ file ... ] List revisions of named files that were last synced from the depot. If no file name is given list all files synced on this client. The format is depot-file#revision - client-file $ p4 have ./... //depot/main/Apps/ActivePython-devel/README.txt#9 - c:\trentm\as\ActivePython-devel\README.txt ... Some notes: - Why "./..."? Firstly, you need to specify a path argument because otherwise p4 defaults to the *whole* client view, which may (and likely does) include directories outside of your current dir. Secondly, "..." is Perforce's way of say "recursively under the given directory". So "./..." as a path argument effectively makes a p4 command behave like an svn/cvs command's default: recursively under the current dir. - If you *do* get into the business of doing this Perforce stuff, you may want to steal from or use my "p4lib.py" (either of which you are welcome todo -- MIT license): http://trentm.com/projects/px/p4lib.py which provides parsing of some of the common p4 commands. (It is not perfect and arguably the Right Thing for Python/Perforce bindings would use Perforce's C++ API. 'p4lib.py' does have the benefit of being pure Python.) >>> import p4lib, sys, pprint >>> sys.displayhook = pprint.pprint >>> p4 = p4lib.P4() >>> p4.have("./...") [{'depotFile': '//depot/main/Apps/ActivePython-devel/README.txt', 'localFile': 'c:\\trentm\\as\\ActivePython-devel\\README.txt', 'rev': 9}, ... ] Cheers, Trent -- Trent Mick TrentM@ActiveState.com
At 06:14 PM 1/24/2006 -0800, Trent Mick 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
[Phillip J. Eby wrote] 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.
[Phillip J. Eby wrote]
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.
How are you getting the list of files in a subversion working copy if not by running svn. Are you using the .svn control dirs? Are the entries file formats publicly speced and guaranteed to stay backward compatible?
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.
Anyway, yah an API for this would probably be good. Cheers, Trent -- Trent Mick TrentM@ActiveState.com
participants (4)
-
bbangert＠groovie.org -
Bob Ippolito -
Phillip J. Eby -
Trent Mick