On 2 June 2017 at 18:37, Paul Moore p.f.moore@gmail.com wrote:
On 2 June 2017 at 08:49, Nick Coghlan ncoghlan@gmail.com wrote:
The last point means that requiring an sdist export command shouldn't impose an unreasonable burden on backend developers, as the only differences between "generate an sdist tree" and "export a build tree" would be:
pyproject.tomlMUST be included unmodified at the root of the sdist treePKG-INFOMUST be generated at the root of the sdist tree- a
setup.pyshim MAY be generated for backwards compatibility with installation tools that are unaware of PEP 517
Note that a full "build an sdist" process should include a means for
authors to add extra files (such as README, LICENSE, ...). But that
can be either something that backends deal with themselves or (better)
gets standardised in a separate PEP (probably defining a new set of
pyproject.toml fields for it). It's not inherently something we need
right now in PEP 517.
I think we can leave this as a backend level thing, as it really is entirely up to the backend. From a frontend's perspective, "Recursively copy everything that doesn't start with '.' and then generate PKG-INFO" would be an entirely acceptable sdist export implementation, as would "Export all files that are under source control and then generate PKG-INFO". More complex backends may want more sophisticated options than that, but they can still go in a backend dependent configuration file (ala MANIFEST.in for distutils/setuptools) rather than needing to be standardised.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia