Log file Viewer
#pypa-dev logs for Monday the 22nd of July, 2019
[12:01:53] <toad_polo> If we built a dedicated tool for it, would that alleviate the desire to make a `pip build` command?
[15:59:20] <toad_polo> dstufft: I think there are multiple different reasons. One of which is that build doesn't *clearly* fit in `twine` or `pip` - there are arguments for both and arguments against both. That makes me lean in favor of it being its own thing.
[16:01:26] <toad_polo> Another thing is that `pip` has some underlying thread tying the semantics of the different commands, including some shared flags, etc. Adding a new tool to try to be consistent with those can be complicated, and leads to an unfortunately constrained design. If you choose *not* to be consistent, you'll get bug reports from people confused by the differences between the commands.
[16:02:19] <toad_polo> Specifically, the semantics of `pip wheel` are really bad for producing wheels for consumption (bad defaults, for one thing), and it would be a pain to either change that *or* to have `pip build` have wildly different semantics.
[16:03:26] <toad_polo> I *suppose* that there might be a case for having a `pip build` tool if we want to change the semantics of `pip` so that it *always* goes repo -> sdist -> wheel -> installation.
[16:03:59] <tos9> Possibly complete side bar in which case tell me to go away, but are there decent numbers on how many people actually use twine relative to pip? And on their opinions on twine's UX? I find twine to be quite clunky in some ways (even though personally I use it)
[16:04:06] <toad_polo> That would be nice for consistency, but I suspect that it would break a whole bunch of stuff in the ecosystem and we'd regret doing it just for the sake of architectural purity.
[16:04:23] <tos9> (I suppose my original thought when this argument was happening on Twitter was "a reason that this should be in pip", but maybe a very weak one, and really a reason to improve twine...)
[16:04:29] <toad_polo> Even then, it would make sense for `pip build` to be like `pip wheel` - a command for marshalling.
[16:05:46] <tos9> toad_polo: I think in general the thing they have to do with each other is "they're the 2 most commonly used end-user packaging tools" I suppose
[16:07:37] <toad_polo> dstufft: Anyway, I talked to EWDurbin about this and he may be working on something like it, but I'm thinking the best way forward would be to continue to build out separate tools for separate functions - `pip` to install packages, `twine` to upload them and some builder tool for building them, then have some omnibus wrapper tool to give people the "npm-like experience" that many people coming from JS seem to want.
[16:10:21] <toad_polo> tos9: It seems difficult to get accurate and meaningful numbers, but are you asking how many people are uploading things to PyPI vs. downloading things?
[16:11:32] <toad_polo> There's a whole bunch of non-PyPI use of both tools internal to some companies that we have no visibility into, so even if the PyPI numbers were meaningful, it'd be hard to say how well those uses translate to the full ecosystem.
[18:30:46] <tos9> toad_polo: but yeah I guess what I mean is "of the fraction of distribution uploads to PyPI, what fraction is twine"
[18:31:40] <tos9> fwiw though if my opinion mattered what you suggested just now makes sense, having 3 tools, but I *suspect* that potentially the "other" suggestion of having it be in pip comes from something like "most people just use pip these days" (hence asking about ^, though yeah taht only covers distribution authors, not end users)
[18:32:46] <tos9> (so as a fraction of *end* users using packaging tools I wonder whether that fraction is even 95% of all users use one tool and it's pip?)
[18:56:32] <toad_polo> There's not really a supported alternative to twine. We'll be removing the upload command soon, and probably adding a required header or something for upload tools that setuptools will never send.
[20:23:46] <sumanah> hi woodruffw! hope you had a good weekend! Would you say now's a good time for me + others to review/test the upload keys PR https://github.com/pypa/warehouse/pull/6084 ? (it's out of date against master now; I can merge master into it or you can)
[20:26:35] <woodruffw> sumanah: hey! yep, now would be good. nlh made some UI improvements that i don't believe have been committed yet, but other than that it should be completely functional :)
[20:50:13] <sumanah> woodruffw: is the test failure on https://github.com/pypa/warehouse/pull/6207 just a Travis blip?
[20:51:40] <woodruffw> sumanah: possibly, looks unrelated in any case (it's happening somewhere in node?)
[21:24:44] <sumanah> woodruffw: ok I'm slowly reaching out to some folks -- once they've had a look or Nicole's commits have merged, I'll reach out to some more
[21:25:58] <sumanah> woodruffw: yeah -- I figure that any testing that the flit people, for instance, can do a bit early will save us potential headaches before we roll the beta out. but also, if di_codes or EWDurbin decide to merge your PR before a lot of other people have tested it locally, that's ok
[21:31:38] <woodruffw> ah yes, ready for review. sorry, i removed the [WIP] from the title but forgot to remove it there