Log file Viewer
#pypa-dev logs for Monday the 2nd of March, 2020
[13:33:08] <toad_polo> I definitely see why people want a single tool that "does everything", but I think that's maybe an illusion.
[13:33:56] <toad_polo> And I think they won't like it when inevitably that means we need to make backwards incompatible changes to their tools.
[13:37:26] <toad_polo> It might be useful to have a wrapper tool that always does the latest thing and is configurable to use something else.
[13:37:45] <pradyunsg> Honestly, at this point, I'm just gonna make a packagebuilder library, that does what pip's buid process does.
[13:39:19] <pradyunsg> All the build logic in pip is disentangled from the rest of the code and, now, idk what to do with it.
[13:40:13] <toad_polo> I feel like "tox but with a sensible default tox.ini if unspecified" where "sensible default" might change over time in potentially backwards-incompatible ways is actually a very useful tool.
[13:41:57] <toad_polo> And possibly what people want when they are looking for "something like cargo" or whatever.
[13:42:50] <pradyunsg> Yea, I'm sort of trying to avoid inducing my biases on the UX folks and, basically, I'm hoping we get some information about what the workflows are and how to support them outta that research.
[13:43:04] <toad_polo> I guess this is another thing to add to the summit proposals. I need to write these down for myself.
[14:26:44] <techalchemy> well actually I'm mostly in favor of ahving ei8fdb do some user research and telling us what people want and seeing if we can produce that
[14:28:06] <techalchemy> one thing I saw people continually struggling with was remembering which tool does which thing, especially if their primary job wasn't 'be an expert in python' but rather 'use python to do your actual job'
[14:28:20] <toad_polo> I'm kind of hoping that the plan isn't to figure out what people want and then give it to them.
[14:29:01] <toad_polo> Because I suspect that the answer to "what do people want" is probably that there are 4-6 very distinct use cases and people in each camp want their use case to work perfectly out of the box using the same tool.
[14:29:33] <techalchemy> oh sure, but like, we have a user experience expert, this is a user experience question, i feel like 1+1 = 2
[14:30:09] <techalchemy> instead of like speculating about how to solve the problem or forcing a solution we can make an informed decision with the help of an expert
[14:30:33] <toad_polo> I assume UX research takes that into account, but there are two additional pretty major factors in play here. One is that we really need to take into account the fact that this is not a solved problem or even a situation where we know all the actual issues involved.
[14:31:05] <techalchemy> obviously the ux researcher doesn't make recommendations in a vacuum or ignoring technical constraints
[14:31:50] <toad_polo> Sure, but I'm saying that maybe a UX researcher could see 1-2 steps down the line, but I doubt that we'll come up with something that will last more than 5 years.
[14:32:18] <toad_polo> The point is that there's a good chance that we can't satisfy the users who want monolithic, stable interfaces.
[14:33:26] <techalchemy> I think we need actual data to back that up, not because I disagree (I don't) but because it will be hard to act on anything until we actually know
[14:33:36] <toad_polo> I could solve this editable installs problem in like 1-2 weeks if I could work on it full time.
[14:34:08] <toad_polo> I mean, I guess it's possible that UX research will turn up that people want a bunch of fast-moving independent tools that they get to choose from.
[14:34:45] <techalchemy> sure, and if we can establish that basically everyone wants a stable interface, but that as long as none of us have time we can't manage that, the next question will be -- ok, so what is necessary to provide a stable api that at least seems monolithic
[14:35:37] <techalchemy> and if the constraint is now that we need some project management and some new full time resources like the ones being dedicated to work on pip, but looking at a more unified approach to packaging, that should be on the table
[14:38:45] <pradyunsg> Yea, IMO once we have some user research information to go by, we can pick up from there and see what we'd want to do with whatever limited movitation-based volunteer dev time we have, see if we want more of X (x = project management, dev time, technical writing, communications etc) and have data on gaps in what users want. I'm sure ei8fdb and techalchemy have a much better idea than me, of what the output of UX
[14:39:03] <pradyunsg> OTOH, I don't think we should be blocking non-controversial tasks on the UX research.
[14:40:28] <techalchemy> like, we can continue making assumptions as needed but I'd hesitate to overhaul anything structural without research
[14:41:26] <pradyunsg> Yea, we're not killing/replacing tool X, unless we know folks aren't using it / it creates confusion.
[14:43:19] <techalchemy> i've had seriously fundamental assumptions challenged by user research like just watching a user try to upload something, I might be slightly fanatical about trying to 'get out of the users way' with software so to speak but we basically scrapped an entire section of our application because clicking an upload button was too hard
[14:46:27] <techalchemy> it was the only thing on an empty state screen besides some text describing the empty state
[14:47:25] <techalchemy> no that can't be right, it must have been in the upper left hand corner above a grid with one empty row
[14:48:29] <techalchemy> still, it was the only button on the page and the only thing that had our primary action color and it had a giant + on it
[15:54:51] <toad_polo> I suspect that people spreading FUD about a bug that existed for like 3 days has created the impression that editable installs don't currently work for projects with a pyproject.toml file, and that we're working to fix that but it's taking forever.
[15:56:42] <toad_polo> When in reality anyone who is "holding off on adding a pyproject.toml because of editable installs" would have *zero* problems adding a pyproject.toml, because what we're working on fixing is making it so you can use PEP 517-only features with editable installs.
[16:03:17] <sumanah> People interested in TUF because of the upcoming PyPI implementation: https://groups.google.com/forum/?fromgroups#!topic/theupdateframework/3Y9O9xwstb4 there's a community phone call happening right now
[16:30:09] <techalchemy> do editable installs not work in some way @ toad_polo? pretty sure i use them everywhere
[16:31:42] <techalchemy> toad_polo, I've heard you mention it a few times and pradyun mentioned it just now and I remember the bug from like the 2018 fiasco when things were broken for a few days (not sure if that's what you mean)
[16:37:15] <toad_polo> I feel like I just explained this while complaining that people think it's broken, which is why I thought it might be a joke.
[16:39:10] <toad_polo> So pip install -e works if it would work when you invoked it with pip 10 or whatever, but not if you don't have a setup.py or anything that requires a PEP 517 build.
[16:40:40] <toad_polo> So it isn't a blocker for anyone adopting PEP 517 builds, but it is a problem for people who want to abandon legacy builds.
[19:53:07] <sumanah> PyCon is planning on happening this year but we'll get weekly updates re COVID-19 potentially affecting this year's con https://pycon.blogspot.com/2020/03/march-2-update-on-covid-19.html
[22:11:02] <travis-ci> Change view : https://github.com/pypa/pip/compare/6637ec3fb655d75a6d055fb8ee50dad4a38efc59...bf0da0fea0021af7a86f76e275a6bfe711b0fccb
[22:11:32] <travis-ci> Change view : https://github.com/pypa/twine/compare/613a6f641fdefb815f6ad9cd20ee98220c5529c5...fb03835ebf124ed2f9a447a5f0bd607c283172fb