On Tue, May 10, 2016 at 6:45 PM, Donald Stufft <don...@stufft.io> wrote: [...] > I think the way this will eventually end up going, is that when we get to the > point of adding that next PEP that allows us to swap out setup.py for a > totally > different interface, is that we'll add something like bootstrap_requires or > something, and do something like "If package.build.requires exists, we'll use > that for build dependencies, else we'll invoke some API in the ABS to get > them".
Hmm, it's not something we have to decide now, but given this roadmap: Now: - a way to specify static requirements before running setup.py Later: - (definitely) a static method for specifying requirements that need to be fulfilled before running the build backend at all ("bootstrap requirements") - (probably) a way to dynamically query the build backend for extra requirements before building a wheel - (maybe) some sort of optimization where we skip the dynamic query if the right static configuration is provided ...I think the simplest way to manage the transition is if we make the-thing-we're-adding-now map to the future "bootstrap requirements". That way we won't have to change the semantics at all. And if we decide we want some sort of static-build-requirements-optimization thing we can make that the new key that we add later. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig