On 2 June 2017 at 18:37, Paul Moore email@example.com wrote:
On 2 June 2017 at 08:49, Nick Coghlan firstname.lastname@example.org 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 tree
PKG-INFOMUST be generated at the root of the sdist tree
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.
-- Nick Coghlan | email@example.com | Brisbane, Australia