On Thu, Oct 8, 2009 at 1:27 PM, M.-A. Lemburg <m...@egenix.com> wrote: > >>> == The fate of setup.py, and static metadata == >>> >>> So we are going to separate the metadata description from setup.py, in >>> a static configuration file, that can be open and read by anyone >>> without >>> running any code. The only problem with this is the fact that some >>> metadata fields might depend on the execution environment. For >>> instance, once "Requires" is re-defined and re-introduced via PEP 314, >>> we will have cases where "pywin32" will be a dependency to have only >>> on win32 systems. > > How are you planning to deal with dynamic version strings, e.g. > say you want to build a snapshot release the current date and > revision number included in the version string ? > > I suppose this file is going to be uploaded to PyPI, so the > file would have to be formatted at build time and include > markers to be replaced with values taken from the distribution > meta-data.
The metadata will always be customizable from setup.py somehow. We won't treat those cases : if the metadata is provided in the static file, you can get it without any further processing, if not you will get an "UNKOWN" value for it and you will have to grab the whole archive and run setup.py to get it. Now the example you've shown is in my opinion not a problem : you can create the static value for "version" that you put in your static file with some pre-processing that occurs when you build your release. (ala autoconf) > >>> - Work left to do : publish the final syntax, and do the implementation > > Is there a PEP for this ? No, but if you ask for it I can write it. > >>> == The fate of bdist_* commands == >>> >>> So the best way to handle this is to ask these communities to build >>> their own tool and to encourage them to use Distutils as a basis for >>> that. > > Rather than having external communities build their own > tools and then basically fork distutils in order to get > these implemented, I think it'd be better to make the > set of distutils commands extensible via namespace packages. I am not sure, why they would fork distutils. Distutils is already extensible, you can configure in distutils.cfg a list of namespace packages, that contains commands and they'll get loaded by dist.py. > >>> So what is going to happen is a status-quo: no bdist_* command will be >>> removed but no new bdist_* command will be added. > > I hope that comment means "no new bdist_* command will be added > *right now*". It's well possible to create new bdist_* commands > that don't rely on external tool chains or only on ones that > don't change often. > > I'm thinking of bdist_inno (Windows installer using InnoSetup) > and bdist_nsis (Windows installer using NSIS) here. As I said, windows don't have any packaging system so I don't think it's a problem to have more installers for this platform. Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
