It can require that it is either unfiltered or an unpacked sdist since that is how a lot of build time projects treat it now. They handle a sdist differently from a vcs source, for example pbr. Swapping out a call to setup.py for an internal shim that calls a Python API doesn't change anything here, randomly filtering out some files from a vcs will break random projects. We ether only suppprt copying the whole directory or we add support for something that enables this in the PEP. There is basically no middle ground that isn't worse than one of those two options for PEP 517 style packages.
I also don't think that creating an sdist should be an optional part of the build interface, but things added in later PEPs can only be added as optional, not mandatory. There is already automation that relies on handling sdist- for example the Travis deployment to PyPI code path- that will be unable to support this new standard without either ONLY supporting wheels, or needing to add custom code for each individual build tool (unlikely to happen). The effect of which will be that either people simply can't use this spec without it or we incentivize releasing only wheels to PyPI instead of wheels and a sdist. I don't see anyway really for this PEP to move forward without support for sdists without causing major regressions. Sent from my iPhone > On May 30, 2017, at 1:36 AM, Nick Coghlan <[email protected]> wrote: > > My rationale for seeing it that way, is that while PEP 517 requires > that the current working directory correspond to the root of the > source tree, it *doesn't* require that the source tree be the > unfiltered contents of a VCS checkout. It can't, since the source tree > might have come from an sdist, and MANIFEST.in and friends already > allow that to be a filtered subset of the full VCS contents. _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
