Distutils 1.0.1 releasee

Hi all -- I've just released Distutils 1.0.1. This is identical to the code in the last snapshot (20001014). And this is the code that will go out with Python 2.0. Now off to deal with the latest bug reports and feature requests... as if things quiet down just because of a major Python release... oh well... Greg -- Greg Ward gward@python.net http://starship.python.net/~gward/

Hello, nice to mail you.
Okay, here is an example. I am using localization .mo/.po files in my program and I need to know at runtime where these files are. So I look in the <packagename>Conf.py module for 'install_data' attribute and search there. After all, should we implement a function to generate such a configuration module? This would be a little like the .ini file for the windows installer. Attached is the function I am using for this now, very rough as usual ;) Bastian # dist.py: # self.config_file = self.get_name()+"Conf.py" def create_conf_file(self, directory, data=[]): data.insert(0, "# this file is automatically created by setup.py") filename = os.path.join(directory, self.config_file) # add metadata metanames = dir(self.metadata) + \ ['fullname', 'contact', 'contact_email'] for name in metanames: method = "get_" + name cmd = "%s = %s" % (name, `getattr(self.metadata, method)()`) data.append(cmd) # write file util.execute(write_file, (filename, data), "creating %s" % filename, self.verbose>=1, self.dry_run)

On 16 October 2000, Bastian Kleineidam said:
Ummm, I'm confused. Is this "info needed to build/install the package", or "info needed to run the software"? Those are two very different kinds of configuration info. The Distutils could probably do something in both areas, but I don't think the two should be confused. Eg. about all we can do for run-time configuration is promote a standard place for Python applications to install and find such config data, whereas we can specify everything about build-time config data. So which are you talking about here? Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ I have a very good DENTAL PLAN. Thank you.

Hi all, Im Jahre 2000 schrieb Greg Ward:
but I don't think the two should be confused. Yes, I agree.
class MyDistribution(Distribution): def __init__(self, attrs=None): Distribution.__init__(self, attrs=attrs) self.config_file = self.get_name()+"Conf.py" def create_conf_file(self, directory, data=[]): """generate a configuration file with all metadata the data supplied in the 'data' argument""" data.insert(0, "# this file is automatically created by setup.py") filename = os.path.join(directory, self.config_file) # add metadata metanames = dir(self.metadata) + \ ['fullname', 'contact', 'contact_email'] for name in metanames: method = "get_" + name cmd = "%s = %s" % (name, `getattr(self.metadata, method)()`) data.append(cmd) util.execute(write_file, (filename, data), "creating %s" % filename, self.verbose>=1,self.dry_run) So create_conf_file generates a file <package>Conf.py. You can call the function from any place in your code (or you can call it never). I call in two places: 1) If I need to store some configuration values, my custom "config" command creates this file with the config values in the 'data' list. 2) When installing. This way the <package>Conf.py is installed as a module and my program has runtime information by importing the module. I think this approach is nice because you can have both configuration and runtime information stored in the file. Furthermore the patch is just adding a function so it does not break any existing apps. Bastian

[Bastian's approach to writing config data]
OK, I think I see what you're getting at here. The fact that participation is voluntary seems nice at first, but doing it that way fails to guarantee a standard way to figure out whether package X is installed on the current system, and which version of X is installed. And the fact that it's "completely general", and can be used for any kind of configuration info, also seems nice at first. But I still think that's wrong: distribution meta-data (name, version, files installed) is different from application configuration data. I think the difference boils down to this: meta-data is fixed, both determined and interpreted by the Distutils, while application config data is (by definition!) entirely application-dependent. The major corollary of this is that end-users might edit application config data, but they had bloody well better not edit installation meta-data. This alone is sufficient justification for keeping them rigidly separated. Also, I *still* don't like Python as a configuration language. It just seems wrong, despite the obvious simplicity of ADMIN_EMAIL = "gward@python.net" FAVOURITE_COLOUR = "greenish-blue" as a config file. I think I'll write up a proposal for storing distribution meta-data. Been mulling it over for long enough, time to write something down. Connected to but independent of this is the need for a standard way to specify, install, and find application-dependent configuration data. The first two are obviously the Distutils' domain; I don't think applications should be dependent on the Distutils at run-time, but we can certainly provide sample code, and make the standard installation location simple and easy so that the boilerplate code to find application config data is simple and easy. Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man.

Hello, nice to mail you.
Okay, here is an example. I am using localization .mo/.po files in my program and I need to know at runtime where these files are. So I look in the <packagename>Conf.py module for 'install_data' attribute and search there. After all, should we implement a function to generate such a configuration module? This would be a little like the .ini file for the windows installer. Attached is the function I am using for this now, very rough as usual ;) Bastian # dist.py: # self.config_file = self.get_name()+"Conf.py" def create_conf_file(self, directory, data=[]): data.insert(0, "# this file is automatically created by setup.py") filename = os.path.join(directory, self.config_file) # add metadata metanames = dir(self.metadata) + \ ['fullname', 'contact', 'contact_email'] for name in metanames: method = "get_" + name cmd = "%s = %s" % (name, `getattr(self.metadata, method)()`) data.append(cmd) # write file util.execute(write_file, (filename, data), "creating %s" % filename, self.verbose>=1, self.dry_run)

On 16 October 2000, Bastian Kleineidam said:
Ummm, I'm confused. Is this "info needed to build/install the package", or "info needed to run the software"? Those are two very different kinds of configuration info. The Distutils could probably do something in both areas, but I don't think the two should be confused. Eg. about all we can do for run-time configuration is promote a standard place for Python applications to install and find such config data, whereas we can specify everything about build-time config data. So which are you talking about here? Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ I have a very good DENTAL PLAN. Thank you.

Hi all, Im Jahre 2000 schrieb Greg Ward:
but I don't think the two should be confused. Yes, I agree.
class MyDistribution(Distribution): def __init__(self, attrs=None): Distribution.__init__(self, attrs=attrs) self.config_file = self.get_name()+"Conf.py" def create_conf_file(self, directory, data=[]): """generate a configuration file with all metadata the data supplied in the 'data' argument""" data.insert(0, "# this file is automatically created by setup.py") filename = os.path.join(directory, self.config_file) # add metadata metanames = dir(self.metadata) + \ ['fullname', 'contact', 'contact_email'] for name in metanames: method = "get_" + name cmd = "%s = %s" % (name, `getattr(self.metadata, method)()`) data.append(cmd) util.execute(write_file, (filename, data), "creating %s" % filename, self.verbose>=1,self.dry_run) So create_conf_file generates a file <package>Conf.py. You can call the function from any place in your code (or you can call it never). I call in two places: 1) If I need to store some configuration values, my custom "config" command creates this file with the config values in the 'data' list. 2) When installing. This way the <package>Conf.py is installed as a module and my program has runtime information by importing the module. I think this approach is nice because you can have both configuration and runtime information stored in the file. Furthermore the patch is just adding a function so it does not break any existing apps. Bastian

[Bastian's approach to writing config data]
OK, I think I see what you're getting at here. The fact that participation is voluntary seems nice at first, but doing it that way fails to guarantee a standard way to figure out whether package X is installed on the current system, and which version of X is installed. And the fact that it's "completely general", and can be used for any kind of configuration info, also seems nice at first. But I still think that's wrong: distribution meta-data (name, version, files installed) is different from application configuration data. I think the difference boils down to this: meta-data is fixed, both determined and interpreted by the Distutils, while application config data is (by definition!) entirely application-dependent. The major corollary of this is that end-users might edit application config data, but they had bloody well better not edit installation meta-data. This alone is sufficient justification for keeping them rigidly separated. Also, I *still* don't like Python as a configuration language. It just seems wrong, despite the obvious simplicity of ADMIN_EMAIL = "gward@python.net" FAVOURITE_COLOUR = "greenish-blue" as a config file. I think I'll write up a proposal for storing distribution meta-data. Been mulling it over for long enough, time to write something down. Connected to but independent of this is the need for a standard way to specify, install, and find application-dependent configuration data. The first two are obviously the Distutils' domain; I don't think applications should be dependent on the Distutils at run-time, but we can certainly provide sample code, and make the standard installation location simple and easy so that the boilerplate code to find application config data is simple and easy. Greg -- Greg Ward - programmer-at-large gward@python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man.
participants (2)
-
Bastian Kleineidam
-
Greg Ward