Convention for installing binary data files
Hi there, I'm a newcomer to distutils, so sorry in advance if this is a question that is too obvious for everyone... I was wondering what the convention is for including binary data files with the installation of a module. Like say I had a table called table.data, that I wanted to have be installed with everything else on python setup.py install - should the data file be part of install_py, or install_ext, or something else? We'd like to use distutils to package up a current project, but weren't sure about this point, and couldn't find it in the docs... --Brian Hooper
On 23 February 2000, Brian Takashi Hooper said:
I was wondering what the convention is for including binary data files with the installation of a module. Like say I had a table called table.data, that I wanted to have be installed with everything else on python setup.py install - should the data file be part of install_py, or install_ext, or something else?
Convention? There is no convention! Distutils currently handles the installation of precisely two types of files: pure Python modules and Python extension modules. Anything else and you're on your own. The good news is, the system is extensible: it's not too hard to augment the standard "install" command to handle whatever type of file interests you. See the NumPy setup script distributed with recent versions of NumPy for an example; visit this charming URL to see it directly: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/Numerical/setup.py?rev=1.8&content-type=text/x-cvsweb-markup&cvsroot=numpy Anyways, what is the nature of this data file? Is it platform-neutral? Does it have anything to do with Python, or is it just an artifact of your project? Under Unix, /usr/share/<your-project> or /usr/lib/<your-project> would probably be good places for it (depending on whether it's platform-neutral or not).
We'd like to use distutils to package up a current project, but weren't sure about this point, and couldn't find it in the docs...
Docs? What docs? ;-) (Don't worry, I'm getting to that!) Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ If you can read this, thank a programmer.
Hi Greg, thanks for the quick response! On Wed, 23 Feb 2000 22:01:49 -0500 "Greg Ward" <gward@python.net> wrote:
On 23 February 2000, Brian Takashi Hooper said:
I was wondering what the convention is for including binary data files with the installation of a module. Like say I had a table called table.data, that I wanted to have be installed with everything else on python setup.py install - should the data file be part of install_py, or install_ext, or something else?
Convention? There is no convention! Distutils currently handles the installation of precisely two types of files: pure Python modules and Python extension modules. Anything else and you're on your own. Are there any plans to include additional hooks for other stuff? Another one that I can think of is documentation - is that typically built as part of the install_ext portion...? What are other people doing with this?
I suppose adding the data file install to 'install' would be all right - it seems like it would be nicer though to be able to have install still just be the sum of its component targets (install_py and install_ext)... (or is that not the way it works?)
The good news is, the system is extensible: it's not too hard to augment the standard "install" command to handle whatever type of file interests you. See the NumPy setup script distributed with recent versions of NumPy for an example; visit this charming URL to see it directly:
Anyways, what is the nature of this data file? Is it platform-neutral? Does it have anything to do with Python, or is it just an artifact of your project? Under Unix, /usr/share/<your-project> or /usr/lib/<your-project> would probably be good places for it (depending on whether it's platform-neutral or not).
It is a platform-neutral data file - specifically, a character mapping table (this is for a Japanese encoding package that a colleague of mine is currently working on)... I guess this would be /usr/lib or /usr/local/lib then? Thanks, --Brian Hoopeer
On 24 February 2000, Brian Takashi Hooper said:
Are there any plans to include additional hooks for other stuff? Another one that I can think of is documentation - is that typically built as part of the install_ext portion...? What are other people doing with this?
My long-term plan is to have specific support for installing certain types of documentation. Anything more concrete than that will have to wait for some standard module documentation system to emerge from the doc-sig. (In other words, don't hold your breath!) However, you've given me an interesting idea: the ability to register certain commands as "sub-install" commands that would then be automatically called by the "install" command itself. Currently, if you want to add some funky new kind of installation, you can either: * subclass the standard "install" command, adding capability to install your custom stuff -- that's the approach I took in adding header installation to NumPy * register your customized version of the "install" command or: * define a new command "my_install" (or whatever) that just does whatever it takes to install your custom stuff * subclass the standard "install" command; the only change is to add a call to your command -- run_peer('my_install') * register both "my_install" and the customized version of "install" However, if we add a way to add arbitrary "sub-install" commands, that simplifies to: * define a new custom "sub-install" command * register it as a "sub-install" command and Bob's your uncle. The same would have to apply to "build" commands -- anything you install (code, documentation, whatever), you usually have to be able to build.
It is a platform-neutral data file - specifically, a character mapping table (this is for a Japanese encoding package that a colleague of mine is currently working on)... I guess this would be /usr/lib or /usr/local/lib then?
No, if you follow the GNU coding standards, platform-neutral stuff goes in /usr/share (or /usr/local/share). /usr/lib (/usr/local/share) is for platform-specific stuff like C libraries. (Now, let's count the number of major packages that actually respect this. You can probably leave your socks on...) Greg -- Greg Ward - Linux weenie gward@python.net http://starship.python.net/~gward/ If you can read this, thank a programmer.
participants (2)
-
Brian Takashi Hooper -
Greg Ward