<p dir="ltr"><br>
On Wed, 7 Oct 2015 18:51 Donald Stufft <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:</p>
<blockquote><p dir="ltr"><br>
On October 7, 2015 at 1:27:31 PM, Nathaniel Smith (<a href="mailto:njs@pobox.com">njs@pobox.com</a>) wrote:<br>
> On Mon, Oct 5, 2015 at 6:51 AM, Donald Stufft wrote:<br>
> [...]<br>
> > I also don't think it will be confusing. They'll associate the VCS thing (a source release)<br>
> as something focused on development for most everyone. Most people won't explicitly<br>
> make one and nobody will be uploading it to PyPI. The end goal in my mind is someone produces<br>
> a source wheel and uploads that to PyPI and PyPI takes it from there. Mucking around with<br>
> manually producing binary wheels or producing source releases other than what's checked<br>
> into vcs will be something that I suspect only advanced users will do.<br>
><br>
> Of course people will make source releases, and should be able to<br>
> upload them to PyPI. The end goal is that *pip* will not use source<br>
> releases, but PyPI is not just there for pip. If it was, it wouldn't<br>
> even show package descriptions :-).<br>
><br>
> There are projects on PyPI right now, today, that have no way to<br>
> generate sdists and will never have any need for "source wheels"<br>
> (because they don't use distutils and they build "none-any" wheels<br>
> directly from their source). It should still be possible for them to<br>
> upload source releases for all the other reasons that having source<br>
> releases is useful: they form a permanent record of the whole project<br>
> state (including potentially docs, tests, working notes, etc. that<br>
> don't make it into the wheels), human users may well want to download<br>
> those archives, Debian may prefer to use that as their orig.tar.gz,<br>
> etc. etc.<br>
><br>
> And on the other end of the complexity scale, there are projects like<br>
> numpy where it's not clear to me whether they'll ever be able to<br>
> support "source wheels", and even if they do they'll still need source<br>
> releases to support user configuration at build time.</p>
<p dir="ltr">We must have different ideas of what a source release vs source wheel would<br>
look like, because I'm having a hard time squaring what you've said here with<br>
what it looks like in my head. In my head, source releases (outside of the VCS<br>
use case) will be rare and only for very complex packages that are doing very<br>
complex things. Source wheels will be something that will be semi mandatory to<br>
being a well behaved citizen (for Debian and such to download) and binary<br>
wheels will be something that you'll want to have but aren't required. I don't<br>
see any reason why source wheels wouldn't include docs, tests, and other misc<br>
files.</p>
<p dir="ltr">I picture building a binary wheel directly being something similar to using fpm<br>
to build binary .deb packages directly, totally possible but unadvised.</p>
<p dir="ltr">Having talked to folks who deal with Debian/Fedora packages, they won't accept<br>
a binary wheel as the input source and (given how I explained it to them) they<br>
are excited about the concept of source wheels and moving away from dynamic<br>
metadata and towards static metadata.</p>
</blockquote>
<blockquote><p dir="ltr"><br>
</p>
</blockquote>
<p dir="ltr"></p>
<p dir="ltr">Your idea of an sdist as something that has fully static build/runtime dependency metadata and a one to one correspondence with binary wheels is not a usable format when releasing the code for e.g. numpy 1.10. It's fine to say that pip/PyPI should work with the source in some other distribution format and numpy could produce that but it means that the standard tarball release needs to be supported some how separately. Numpy should be able to use PyPI in order to host the tarball even if pip ignores the file.</p>
<p dir="ltr">If numpy released only source wheels then there would be more than one source wheel for each release corresponding to e.g. the different ways that numpy is linked. There still needs to be a way to release a single file representing the code for the release as a whole.</p>
<p dir="ltr">--<br>
Oscar </p>