
<!DOCTYPE html>

<html>

<head>

<title></title>

</head>

<body><div>On Wed, May 31, 2017, at 07:40 PM, Donald Stufft wrote:<br></div>

<blockquote type="cite"><div>Taking pip completely off the table a second, let’s take a look at tox. Tox’s default mode of operation is to produce a sdist. Now let’s say I’m writing a project that I want to use PEP 517 and get rid of setup.py, except now tox is broken with no path forward because PEP 517 doesn’t define how to produce a sdist. <br></div>

<div><div><br></div>

<div>The same story is true for TravisCI’s PyPI deployment pipeline, as soon as any project starts depending on PEP 517, we completely break that feature for them without a path for them to fix it (besides writing a PEP of course).<br></div>

<div><br></div>

<div>The same is true for Gem Fury’s private PyPI repositories where you can ``git push fury`` and have them build a sdist automatically for you.<br></div>

</div>

</blockquote><div><br></div>

<div>These tools are all things that the developers of the project choose to use, however. I don't use them, so I'm happy enough to get rid of setup.py and not have a standard interface to building sdists. Developers who do use them will want to stick with setup.py until there's a standard way to build an sdist - or a tool like tox may add support for going via wheels instead of via sdist.<br></div>

<div><br></div>

<div>So PEP 517 may not be useful to *everyone* without standardising a way to build sdists, but it is still useful for many projects, and I don't think it prevents a later PEP from standardising a way to build sdists.<br></div>

</body>

</html>