Because the status quo, which is a single format, sucks. I don't think changing it so we invoke a Python function instead of a script is going to make it not suck. The fundamental reason it sucks (in my mind) is that we have a single format trying to do way too many things and we need to break that out into smaller chunks.
You can see these needs are different I think by looking at how what Nathaniel wants differs from what me and Paul want. He wants something that will make the human side easier and will support different tools, we want something that pip can consume more reasonably. Trying to do too much with a singular format just means it sucks for all the uses cases instead of being great for one use case. I also don't think it will be confusing. They'll associate the VCS thing (a source release) as something focused on development for most everyone. Most people won't explicitly make one and nobody will be uploading it to PyPI. The end goal in my mind is someone produces a source wheel and uploads that to PyPI and PyPI takes it from there. Mucking around with manually producing binary wheels or producing source releases other than what's checked into vcs will be something that I suspect only advanced users will do. Sent from my iPhone > On Oct 5, 2015, at 9:39 AM, Antoine Pitrou <[email protected]> wrote: > > On Mon, 5 Oct 2015 09:28:48 -0400 > Donald Stufft <[email protected]> wrote: >>> >>> In any case, sdists being apt for human consumption is an important >>> feature IMHO. >> >> I don't think so. Remember in my footnote I mentioned that I wasn't using VCS >> to mean literally "something checked into a VCS", but rather the more >> traditional (outside of Python) "source release" concept. This could be a >> simple tarball that just has the proper, for human consumption, files in it >> or it could be a VCS checkout, or it could just be some files sitting on >> disk. > > But why use two different formats for "source release" and "sdists"? > Currently sdists fit the assumptions for a source release, why > introduce some complexity and have the users deal with separate > concepts (with all the confusion that will inevitably ensue)? > > Regards > > Antoine. > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
