On Jun 1, 2017, at 9:40 PM, Jeremy Stanley <fungi@yuggoth.org> wrote:

On 2017-06-01 21:09:57 -0400 (-0400), Donald Stufft wrote:
I think a separate tool for each of these roles is somewhat user
unfriendly TBH.

I'll do my best not to be offended that you don't consider me a user
(or representative of some broader class of users). ;)

I probably should have written out the long form: unfriendly to users who aren’t steeped in packaging lore ;)

At any rate, I think it depends on your definition of users. Some
users want one shiny kitchen-sink tool that does everything for
them, others want composable tools with well-considered bounds of
operation. It's possible a modular approach could satisfy both, but
then again if twine grows too many features I'm just as likely to
write a new lightweight API client instead so I can have something
auditable I can trust my credentials to which only knows how to

Largely to me it’s about not throwing a ton of different things at people that they have to both find and learn. It’s easier to keep things consistent in a single code base (lol Unix which has -R and -r for recursive depending on your tool!) and also easier for people to discover the different commands they need to fully manage a project. This can get particularly difficult when the multitude of different tools evolve at different paces (we see this today where pip will support something but setuptools won’t yet, etc) which requires people to have to care about the versions of more different tools.

I also think it’s perfectly fine to have another tool that competes with twine (or part of twine) that takes a different set of trade offs. Part of the goals of documenting standards around these things instead of just going “well setuptools is the thing you need to use and that’s just it” you can go ahead and write your thing that scratches your particular itch better, and they can have a friendly competition ;).

At the end of the day though, this is a bit of a tangent since it doesn’t matter wether it’s ``pip sdist``, ``twine sdist``, or ``make-me-and-sdist-plz``, the underlying point of having a command to handle that stands.

Donald Stufft