On Mon, Aug 27, 2012 at 10:56 AM, Daniel Holth <dho...@gmail.com> wrote: > On Wed, Aug 15, 2012 at 10:49 AM, Daniel Holth <dho...@gmail.com> wrote: >> I've drafted some edits to Metadata 1.2 with valuable feedback from > ... >> (full changeset on >> https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068) > > Metadata 1.2 is nearly 8 years old and it's Accepted but not Final. Is > it better to continue editing it, or create a new PEP for Metadata > 1.3?
Somehow I completely overlooked this thread until now. Thanks Daniel for getting the ball rolling on this. There have already been many bytes spilled on metadata extensions, and although I agree it would be enormously useful to build an extension mechanism into the metadata format, I don't have much riding on that, or much more to add that hasn't been said. There hasn't been much said about Setup-Requires-Dist, so I'm guessing it's uncontroversial. But since that's sort of my hobbyhorse I thought I would make a comment on it. The thing I love about the Setup-Requires-Dist feature is that, if properly supported by different installers, it can free those installers from a fair bit of responsibility. For example, in greatly simplifies the thorny issue of "compilers". The existing compiler support in distutils, while not without its problems, does work in most cases for building common C-extensions. distutils2 has already made some progress on cleaning up the interface for compilers, and making it easier to register new compiler classes that can be imported from an arbitrary package. This allows projects with special needs (such as Fortran compiler support) to ship their own compiler class with the project. Or if there's a good enough third-party package that provides Fortran compiler support, projects may use it in their build process. Support for Setup-Requires-Dist ensures that a third-party compiler package can be made available at build-time. What's great about this, is that even if the stdlib still includes a build system, it doesn't necessarily have to anticipate every possible need for building every kind of project (it should, at a minimum, be able to build pure-Python projects). If someone wants to add MSVC2012 support they can do that as a third-party package. One could even create "compilers" for other build systems like waf, or even provide an entry-point to meta-build systems like bento. Am I making sense? Erik _______________________________________________ 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
