See how trivial it would be to put the delegated sdist generator into the build-backend within the confines of the current PEP? The build-backend could point to a .py in the current directory that implements itself with different tools, or a delegating build backend could parse a separate source-backend out of pyproject.toml for kicks. So why worry?

On Fri, Jul 28, 2017 at 4:30 PM Leonardo Rochael Almeida <leorochael@gmail.com> wrote:

Hi Thomas,

On 28 July 2017 at 16:53, Thomas Kluyver <thomas@kluyver.me.uk> wrote:

[...] I have a nagging concern about something that someone mentioned ages ago: does it make sense for building sdists and building wheels to be part of the same backend?

[...]

So I'd like us to circle back round and reconsider allowing projects to specify 'use tool X to make wheels, and tool Y to make sdists'. If everyone else thinks that's unnecessary, I think we'd all be glad to finish this discussion up, but this concern has been growing in my mind for a while, and I want to get it out there before we finalise the PEP.

Great, now you've planted your nagging concern on my mind as well ;-)

What would using different backends for sdist and wheel look like? Something like this?

# pyproject.toml
[build-system]
requires = ["sdister", "wheeler"]
source-backend = "sdister.api:main"
build-backend = "wheeler.api:main"

If it's something like the above (or even, if it's a different section (`source-system`? I'm trying hard to avoid the `sdist` word), then perhaps this could be developed in a future pep without much issue. considering what Daniel just reminded us about tools being able to claim ignorance on how to develop sdists.

But if it's also that simple, maybe it could be added to this pep (/me ducks).
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig