On 28 July 2017 at 15:34, Nick Coghlan <ncogh...@gmail.com> wrote: > On 28 July 2017 at 13:30, Nick Coghlan <ncogh...@gmail.com> wrote: >> On 28 July 2017 at 01:32, Jason R. Coombs <jar...@jaraco.com> wrote: >>> I’d like feedback, in either ticket, about whether this change is worth the >>> trouble and if so if there are any ways to mitigate the risks of introducing >>> such a change. >> >> The one way I can see of doing this with a graceful transition period >> would be to implement it like this: >> >> 1. Switch to raw parsing with no interpolation as the default >> 2. Check the result for any field values containing either "%(<text>)s" or >> "%%" >> 3. If you find any, print a suitable deprecation warning and parse it >> again with interpolation enabled > > Clarifying to add: I think this is a worthwhile change, as it helps to > ensure that the static config files actually *are* static, and hence > less dependent on being read specifically with Python's configparser > library. That's a boon for interoperability, even if it means that > folks that genuinely want interpolation will need to switch to a > "setup.cfg.in" style approach where they use the templating tool of > their choice to read in the input file, substitute values, and then > write out a completely static setup.cfg file.
Yeah, I'm going to disagree here. While its true that using interpolation binds the config file semantic interpretation to Python, its *already* bound that way due to the idiosyncratic continuations style and nested sections. Doing a .in -> actual-foo is a great pattern for build systems building expensive artifacts with complex dependency chains. Not problems have, and copying their solutions without the problem is just unnecessary, and unhelpful, complexity. +1 from me for retaining interpolation. -Rob _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
