On 2 June 2017 at 18:37, Paul Moore <p.f.mo...@gmail.com> wrote: > On 2 June 2017 at 08:49, Nick Coghlan <ncogh...@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.toml` MUST be included unmodified at the root of the sdist tree >> - `PKG-INFO` MUST be generated at the root of the sdist tree >> - a `setup.py` shim 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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig