On 31 August 2016 at 07:04, Daniel Holth <dho...@gmail.com> wrote: > In other systems I've worked on I sometimes have make-like rules that > automatically rebuild static metadata depending on other files, like copying > a version number between a .json and an .xml file - reprogramming the system > that uses the .xml file is not an option. For example a rule could watch > certain files in the .git directory to regenerate a version number > automatically as part of the build if .git changed, and do nothing if the > .git directory was absent per a tarball dist. This works pretty well. Once > you have a system that's easy to customize with make-like rules there are > all sorts of trivial build or housekeeping tasks you might decide to do > which would never be considered in a more difficult to customize system.
CPython's own build process takes this to extremes by sometimes bootstrapping a version of Python without an import system in order to refreeze importlib before continuing with building the normal version. Argument Clinic (which generates C function argument handling preambles from specially formatted comments) similarly needs a pre-existing Python build in order to run. However, we successfully hide that complexity from folks that just want to build their own Python from source by checking in the generated files. Similarly, it wouldn't astonish me if we eventually see an emergent practice of people writing pyproject.toml.in files for complex projects, in order to move some particular forms of complexity away from build time and towards development time - this would be a similar practice to folks using autoconf to generate a project's C Makefile. Party of the beauty of the pyproject.toml format is that as publication and installation system maintainers, we don't need to care about this problem beyond ensuring that "maintain it by hand" is a viable and fully supported option for the majority of projects - as long as the resulting file gets checked in, folks are free to autogenerate from another data source if they choose to do so. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
