On Thu, Feb 11, 2016 at 11:16 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 11 February 2016 at 17:50, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > On Wed, Feb 10, 2016 at 2:43 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > >> > >> On 10 February 2016 at 13:23, Nick Coghlan <ncogh...@gmail.com> wrote: > >> > On 10 February 2016 at 20:53, Paul Moore <p.f.mo...@gmail.com> wrote: > >> >> We don't have to solve the whole "sdist 2.0" issue right now. Simply > >> >> saying that in order to publish pypa.json-based source trees you need > >> >> to zip up the source directory, name the file "project-version.zip" > >> >> and upload to PyPI, would be sufficient as a short-term answer > >> >> (assuming that this *would* be a viable "source file" that pip could > >> >> use - and I must be clear that I *haven't checked this*!!!) > > > > > > This is exactly what pip itself does right now for "pip install .", so > > clearly it is viable. > > > >> until > >> >> something like Nathaniel's source distribution proposal, or a > >> >> full-blown sdist-2.0 spec, is available. We'd need to support > whatever > >> >> stopgap proposal we recommend for backward compatibility in those new > >> >> proposals, but that's a necessary cost of not wanting to delay the > >> >> current PEP on those other ones. > >> > > >> > One of the reasons I went ahead and created the specifications page at > >> > https://packaging.python.org/en/latest/specifications/ was to let us > >> > tweak interoperability requirements as needed, without wasting > >> > people's time with excessive PEP wrangling by requiring a separate PEP > >> > for each interface affected by a proposal. > >> > > >> > In this case, the build system abstraction PEP should propose some > >> > additional text for > >> > > >> > > https://packaging.python.org/en/latest/specifications/#source-distribution-format > >> > defining how to publish source archives containing a pypa.json file > >> > and the setup.py shim. > > > > > > The setup.py shim should be optional right? If a package author decides > to > > not care about older pip versions, then the shim isn't needed. > > Given how long it takes for new versions of pip to filter out through > the ecosystem, the shim's going to be needed for quite a while. Since > we have the power to make things "just work" even for folks on older > pip versions that assume use of the setuptools/distutils CLI, it makes > sense to nudge sdist creation tools in that direction. > > The real pay-off here is getting setup.py out of most source repos and > replacing it with a declarative format - keeping it out of sdists is a > non-goal from my perspective. > I don't feel too strongly about this, but: - there's also a usability argument for no setup.py in sdists (people will still unzip an sdist and run python setup.py install on it) - it makes implementing something like 'flit sdist' more complicated; without the shim it can be as simply as just zipping the non-hidden files in the source tree. - if flit decides not to implement sdist (good chance of that), then people *will* still need to add the shim to their own source repos to comply to this 'spec'. Ralf
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
