On Fri, Jan 30, 2009 at 12:34 AM, Floris Bruynooghe <floris.bruynooghe@gmail.com> wrote:
setup.cfg could be used in that case.
setup.cfg is a configuration file to be edited by developers. Going to modify that at build time is guaranteed to result in unhappy people at some stage I reckon.
right
But having a .py file would allow having some values calculated dynamically,
But those could be calculated at the time setup.py runs too.
If it's not directly a .py file there needs to be an stdlib module to access it easily, manually using ConfigParser is not an option IMHO, I'd rather do `import foo; foo.prefix'.
An argument against a generated .py file is that this won't work for single-module python distributions. But having a .cfg file or something next to the module/package might defeat the point of trying to help the FHS in violating it already. OTOH .egg-info does that too and seems to be accepted currently.
Well, the egg-info file is the static version of setup.py metadata in some way, I would find a new file redundant. I am really curious though, to see what the file would contain.. from my current understanding, and having in mind to introduce such a file in a way things can gently evolve: What if an egg-info-like file was present in the package from the very beginning, describing the package metadata, and used by setup.py, *and* at build time by third party tools. (with setup.py knowing that it can be changed at run time) egg.info file: ========= Metadata-Version: 1.0 Name: foo Version: 1.0 etc.. *new metadata modified at build time* ========= setup.py file: ========== from disutils.core import setup, get_metadata static_metadata = get_metadata() static_metadata['more_things'] = 'xxx' setup(**static_metadata) ========== Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/