On Tue, Sep 8, 2009 at 2:32 PM, Eric Smith<e...@trueblade.com> wrote: > Tarek Ziadé wrote: >> >> On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers<ch...@simplistix.co.uk> >> wrote: >>> >>> Tarek Ziadé wrote: >>>> >>>> - an extra function called "long_description", to be able to point a >>>> file for the long description field >>> >>> I can't comment on the others, but this is unnecessary. Why do you need >>> more >>> than: >>> >>> long_decription="some lump of text" >>> >>> or >>> >>> long_description_path ="path/relative/to/directory/containing/setup.py" >>> >>> ...with it being an error for both to be specified? >>> >>> cheers, >>> >> >> The practice in the community is to create the long_description field >> using a separate reStructuredText file >> and reaching it in setup.py like this for example: >> >> long_description = open('README.txt').read() >> >> Having a callable that provides this feature in the template allows >> writing: >> >> """ >> [setup.cfg] >> >> long_description: {$ long_description('README.txt') $} >> """ >> >> Thus avoiding to write anything in setup.py for that particular case. >> the callable could be called "read_file()" maybe, so it's clearer. >> >> long_description_path can't be added in the final PKG-INFO because >> we want a self-contained metadata static file that doesn't require an >> extra resource (like an external file) >> >> Whereas having a file path in setup.cfg.in is acceptable, as long as >> the resulting setup.cfg >> contains everything needed to get the metadata of the package without >> further depenencies. >> >> so if by the time setup.cfg.in is compiled, the path cannot be found, >> the field will have its value set to "UNKOWN" in setup.cfg > > Which all points out that it's setup.cfg that is the static metadata, and > that you can generate it any way you want. If you want to use m4, use m4. If > you want to use python, use python. If you want to have some makefile driven > approach, or use autoconf, or whatever, do that. > > setup.cfg should be entirely static except for some simple if-then-else > logic involving versions, as Tarek has described earlier. That is, it should > only contain logic that needs to be decided on the platform where the > installation is taking place. This is basically what RPM provides. > > Any other logic, in particular logic used solely for building setup.cfg, > should be outside the scope of this system, because you can use any tool at > all for it. >
So you are suggesting that setup.cfg includes the "if/else" logic instead of having it in a "setup.cfg.in" file ? In that case, if we want to keep a configparser-compatible file, we need to find another way to express these if/else parts, which will probably lead to a complex, non natural syntax. Having a "setup.cfg.in" file with if/else logic in it, to build the setup.cfg independanlty from the package code, using a function provided by python's stdlib, allows us to have a simple syntax. Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースの岩! _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig