[Distutils] [Bulk] Re: Files under /etc and /usr/share

[Vincenzo Di Massa]

Alle 17:49, domenica 18 settembre 2005, hai scritto:
> At 12:38 PM 9/18/2005 +0200, Vincenzo Di Massa wrote:
> >Is it possible to install things into /etc using setuptools/easy_install?
> > I think that this feature will be very appreciated.
> >I know setup.py philosopy is to put everything inside eggs, but config
> > files are a really special case!
> >It would be nice beeing able to tell in setup.py what the config
> > files/dirs are. The generated egg should install the config files on user
> > request (using a gen_config script) or just when the neded are not config
> > files on the system.
>
> I think that this is very application-specific as to how it should be
> handled.  It's very easy to create a package that contains configuration
> files, with a function in __init__.py to install them, perhaps with some
> options or an interactive setup facility.  Listing the function in setup.py
> then allows a script wrapper to be created for setting up the data.
>
> Using pkg_resources.resource_filename() with a directory resource will
> unpack an entire directory tree to a temporary location, or give you the
> location of files that are already unpacked, so you can then use shutil or
> other normal ways of copying files.

What you say seems to be the right thing (tm) :-).
What I am proposing is nothing more that a convention to do config files 
installation.
Maybe it is just something that can be explained into the documentation. It 
would be nice to ask setup.py writers to adopt the "best practice" that you 
descibed before. Maybe we can define what the name of the function is and 
what parameters it requires: this will make easy and obvious what is the 
right way of handling config options.
Once the function name is standardized... why not provide a default 
implementation that automatically installs the files you specify somewhere?
It is tedious to have to write code to just handle a little set of config 
files.
It is a very common use case, so it would be good to provide some authomatism 
to:
1) make the distribution of many modules easier
2) provide a standard way to do one thing

> >Another idea is for heavy data. Consider for example moin_moin.
> >Using easy-deb i managed to aotomatically pacakge it into an egg (which is
> >contained into a deb-package). The problem here is that it installs the
> >template files inside the egg. Since template files must be copied
> > "somewere" it is bat to put them into the egg where they are
> > hidden/zipped. Moreover it would be nice to make the eggs inside
> > /usr/lib/python?.?/site-packages more lightweight removing package data
> > from them.
>
> I don't really agree.  Projects with this kind of data are best off if they
> provide a custom installation tool.  Well, I should say that their *users*
> are best off if they provide an installation tool, rather than dumping the
> files in one place.  Further, it is easier to support global installation
> of a package for multiple users, or for a single user with multiple
> installations of the tool.  (E.g. multiple wikis.)  If the data
> installation is done by easy_install, it can only be done once, and without
> any real options as to how it's done.  If it's done by a function included
> with the package, then it can be done as many times as desired, and with
> whatever options the project wants to provide the user with.

I did not explain myself very well, sorry. What you say is absolutely right!
What I meant is:
Suppose you have a module that has a an installation tool that is able to 
install data files/templates to multiple dirs at different times. All the 
copies are taken from somewhere. Now the source copy is inside the egg. My 
proposal was to move the source copy out of the egg. The reasons are:
1) you should be able to modify the default template
2) the template can be big an big templates belong to something different 
from /usr/lib/python?.?/...
3) provide a standard way to do one thing

Maybe setuptools could optionally put a couple scripts inside generated eggs 
that can:
1) put default config files in place
2) move the templates somewhere else (like /usr/share)

This way config files and data files could be handled automatically like 
setuptools does for dependencies: before executing the module could call 
pkg_resurces.config_files("modulename") and 
pkg_resources.data_files("modulename") to make sure that the config files 
exist and that data files are where they shuold be.

> >There are 2 kind of package data: data that is used *by* the module code
> > and data that is used *with* the module. moinmoin is just an example of
> > module whose data is not used by the code but with the code.
>
> Well, in my way of thinking, such templates *are* used by the code, it's
> just that they should be used by the project's "instance install/config"
> script(s).

I understand your point of view, any template can be seen as used by the 
module's code, but...
There is a little difference: there is data that the user will hand edit, and 
data used an modified only by the module. There is data that must installed 
only once, and data (like moinmoin templates) that can be installed multiple 
times.
I wanted to distinguish data that can be somehow "hidden" from data that must 
be "visible".

> >Another nice thing to have in setuptools is a --nodeps option. Packagers
> >really need to install an egg (into a package of course) even if its
> >dependencies are not on the system. Skipped dependencies could be reported
> >inside a skipped_deps.txt file or on stdout (so that packagers can add the
> >dependency info to the generated packages).
>
> We could have a --record-deps option, but you can also just pull the
> dependencies from the Distribution.requires() method.  I have had it on my
> list to have a --no-deps option, though, I just haven't gotten around to it
> yet.

You are doing a really good job with setuptools! I really like how they are 
now. I'm just trying to add my 0.02€ :-) I hope I'm not adding -2€

Ciao
Vincenzo

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it