On 17 July 2013 22:40, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > On 17 July 2013 13:17, Nick Coghlan <ncogh...@gmail.com> wrote: >> That said, the new metadata standard does deliberately include a few >> pieces intended to make such things easier to define: >> >> 1. The extensions concept - using a structured data format like JSON >> makes it much easier for platform specific tools (or even pip itself) >> to say "declare this metadata, and we will run these commands >> automatically" > > Okay, so this is where you can put the "I need a [specific] > C-compiler" information. Then a pip alternative (or a future pip) that > knew more about C compilation could respond appropriately. > > The PEP doesn't explicitly say anything about how a tool should handle > unrecognised metadata extensions; it seems fairly obvious to me that > they are supposed to be ignored but perhaps this should be explicitly > stated. > > On the other hand it would be useful to be able to say: if you don't > understand my "fortran" metadata extension then you don't know how to > install/build this distribution. Is there a way e.g. to indicate a > build/install dependency on the tool understanding some section in the > extension metadata, or that an extension is compulsory somehow?
Yes, you can include a build_requires on something that understands the extension and make setup.py a shim that invokes that build system rather than setuptools/distutils (similar to the way d2to1 allows setup.cfg based projects work with tools that are expecting a setup.py file) It's not as elegant as a proper metabuild system (since there's a fair bit of legacy cruft in the setup.py CLI), but it works :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
