Log file Viewer
#pypa-dev logs for Friday the 30th of March, 2018
[18:03:07] <jaraco> @pombreda the bot is back, but I don’t think there’s any way to know why it went missing.
[18:03:57] <techalchemy> sumanah: I didn't want to do the whole 'introduction' thing during office hours so I figured I'd substitute by checking out your company, the headline caught my eye
[18:04:57] <jaraco> Weird that logs were rotated, given that there’s nothing special set on journald to cause them to rotate so aggressively.
[18:06:37] <sumanah> techalchemy: Thanks. https://changeset.nyc/resources.html is in a sense "me having Opinions about open source, at length, but with sort of a table of contents" :)
[18:11:22] <pombreda> hum, the lack of immediately visibility of a package download URLs on the new Pypi is troubling to me: I need to make a click to see these, this means one extra click to see valuable info. I wonder if this could be displayed alright still this is already in the HTML? sumanah, dstufft do you care for a ticket?
[18:11:32] <techalchemy> sumanah: unfortunately not at the moment, I never could manage to keep a blog. Professionally I currently am part of a very small software team at a relatively large company that makes IOT/'smart' metering devices
[18:12:41] <sumanah> pombreda: so about every time you go to PyPI to look at a project page because you're going to be installing the project, you want to download the package file to do the install?
[18:14:11] <pombreda> sumanah, sure thing. I do want to check the downloads to see if there is a wheel or not for my platforms. I will download it for sure by hand in all cases, and in some case will build extra wheels. And I want to see the checksum too. I do not trust the code to be what it is otherwise.
[18:14:20] <sumanah> pombreda: as I understand it, most of our users use `pip` to install packages rather than directly download those wheels and sdists. But if a high enough proportion of our users basically always want to directly download wheels & sdists, I want to know about that, and there might be several ways to accomplish this
[18:15:24] <sumanah> Right, in the convenience-control spectrum, you way prefer control to convenience.
[18:15:38] <Wooble> I never download the wheels manually, but I very often check which ones are there for a package.
[18:17:07] <pombreda> Wooble, that's also a frequent use case especially when there is no wheel, or for package with native code
[18:17:20] <pombreda> sumanah, Now I can appreciate a more convenient experience for the less discerning user alright. But I should not have to do more clicks or resort to view the HTML source to see all the information that's available on the page
[18:18:21] <pombreda> sumanah, I guess I could have some userscript alright to re-surface that data present in the HTML page too :P but that would kinda weird, would it?
[18:20:07] <pombreda> I guess to me it feels like you create a nested tree browsing experience with two levels.
[18:21:58] <thea> I think there is something to be said about surfacing whether a package has wheels available on the description page.
[18:23:50] <pombreda> all that, and if there are wheel(s): which os, python, etc. and if there is an sdist too :P
[18:24:07] <sumanah> pombreda: ok. are you reasonably happy with how the current packages view presents that info?
[18:25:29] <pombreda> sumanah, the view is fine. More compact and denser information is always my taste, but that's minor. I might have expected to have keywords hyperlinked and an alternate to browse from classification too. But that's minor
[18:25:58] <sumanah> pombreda: the hyperlinked keywords is an interesting point and I hope you'll file that as a feature request in GitHub
[18:26:09] <dstufft|laptop> Probably one thing we should do if people are looking to figure out if a wheel exists for their OS/python/etc is to parse the wheel filename for them
[18:26:20] <sumanah> pombreda: and I'm interested in understanding what you mean by "an alternate to browse from classification" if you could talk about that too
[18:26:47] <thea> dstufft|laptop: that was my thought, like we could show a (Universal) badge or a series of (Windows) (Linux) (Mac) badges.
[18:26:48] <dstufft|laptop> you probably shouldn't have to mentally parse an obscure packaging format to know "is pip install .... going to install a binary dist or need a compiler"
[18:27:04] <sumanah> dstufft|laptop: if someone really wanted to do an April Fool's feature for PyPI, they could make special "wheel-enabled" CSS for such projects, where the project name "wheels" around the screen???
[18:27:31] <dstufft|laptop> I mean, I can parse the filenames but I'm a werido who memorizes packaging PEPs soooo
[18:28:02] <sumanah> ok, my jokey suggestion is logged for posterity, someone else can do it, I shall move on to other bits of pombreda's request
[18:29:02] <sumanah> pombreda: so one thing I've been experimenting with is viewing a few pages on pypi.org, like https://pypi.org/project/lifelines/ just as an example, in Firefox, and then choosing View: Page Style: No Style
[18:29:38] <sumanah> Because if you do that, you do see all the major Navigation "pages" -- Project Description, Release History, and Download Files, all on one page.
[18:30:32] <pombreda> sumanah, re: "an alternate to browse from classification" I mean by hypothetically clicking on the keyword of the package, I would see a list of packages that share the same keyword. And these keywords could be also listed in the "list views" that show the search results pretty much the same way you get "facet"-like browsing from the classification
[18:31:10] <pombreda> sumanah, I am not sure if keyword are widely used enough for this to be worthy, so this is more a nice to have (which would be a step up from old pypi)
[18:33:52] <pombreda> dstufft, re: "you probably shouldn't have to mentally parse an obscure packaging format" ...
[18:34:05] <sumanah> thea: do you have a moment to file an issue about the idea of surfacing wheelitude on project description pages for releases that provide wheels?
[18:34:41] <pombreda> dstufft, what's wrong with making sense of this? lxml-4.2.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl everyone can make that in a glance? right? :D just kidding
[18:36:07] <sumanah> and pombreda right now I want to gather more data about what our users are looking for, whether clicking that extra link to get to the package listing is an annoyance that persists or fades or grows, and whether there are other creative ways to accommodate you and users like you -- this is a perfect Nicole usability test question, I think.
[18:38:20] <pombreda> sumanah, re "Page no style" I am old scholl and I like it plain, but not "that" plain :P unless you rework the no-style, bare html to look decently organized ;)
[18:40:04] <pombreda> sumanah, re: "this is a perfect Nicole usability test question, I think." : ack
[18:41:06] <pombreda> https://duckduckgo.com/?q=%22Nicole+usability+test+question%22 -- > No results. .... me being silly again :)
[18:51:12] <sumanah> pombreda: Wooble ^ feel free to comment there if I haven't summarized your thoughts well
[18:51:58] <pombreda> sumanah, and I see you also link to https://libraries.io/ (they are good buddies). neat
[19:03:03] <pombreda> sumanah, another thing: the URL to the homepage is hidden now (compared to old pypi). So I need to hover first to determine if this is some home page vs. a github repo page with the actual code before I click ;)
[19:05:36] <sumanah> techalchemy: so I think part of what's up here is that different projects think of different things as their homepages, right?
[19:06:25] <pombreda> but when there is an actual page that points to an actual code repo (GH, BB, etc) that's valuable information to me.
[19:06:27] <sumanah> and the Project-URLs feature and how we surface those, e.g., on https://pypi.org/project/sphinx-epytext/ , https://pypi.org/project/twine/ , will probably shape customs....
[19:06:59] <sumanah> pombreda: so part of what we ought to do is try to get package maintainers to have a Project-URLs list that includes a link to the source code repo
[19:08:52] <sumanah> (in US government-run schools, a "field trip" is a school-organized trip where teachers and parents take children on a half-day or one-day expedition to a place outside school, and there are organized educational activities)
[19:09:45] <sumanah> so there's "Home-page (optional)" and if a release uses it, we should do special things with it, and I think we do
[19:10:56] <sumanah> clearly we're doing something special regarding GitHub links in "Project-URL (multiple-use)" because look, there's a GitHub logo in https://pypi.org/project/twine/
[19:13:28] <pombreda> :) well if the "Home-page" or "Project-URL" contains a link to a well known hsoting service such a Gitlab, Bitbucket or GitHub is would be useful to surface this OR leaing the URl link visible would work too for me . An icon is sweet too
[19:14:01] <anowlcalledjosh> iirc there's an open issue on warehouse about having the right icon, will see if I can find it
[19:19:04] <dstufft|laptop> it's implemented of "mandatory" was, "if the user doesn't provide them, we will replace them with ``UNKNOWN``"
[19:19:56] <dstufft|laptop> -sig probably had something to do with it, but this is a code thing not a mailing list thing :P
[19:25:12] <dstufft|laptop> I think practically speaking, the only mandatory values are Name and Version
[19:25:58] <dstufft|laptop> and in legacy PyPI not even those were "mandatory" (in that it would accept the UNKNOWN values, whereas warehouse strips UNKNOWN out, or should)
[19:35:27] <thea> Also o/ I would love to get my readme_renderer PRs related to Github-flavored Markdown merged and cut a new release today. I know di_codes is maybe a bit too busy to review, but is anyone else able/willing?
[19:53:21] <techalchemy> dstufft|laptop: I would be opposed to mandatory values, I would jsut want a place that I _know_ would contain a repository if indeed there was one
[20:42:09] <sumanah> thea: I was basically interviewing dstufft to get an inventory of the projects he's working on
[20:42:26] <sumanah> thea: I am done now! (for now.) so I've asked dstufft|laptop whether he can review your PR. link?
[20:55:06] <thea> also https://github.com/pypa/readme_renderer/pull/69 (EWDurbin has approved, but I can't merge)
[20:56:22] <thea> sure. I mentioned before to di_codes that I'd be happy to be a co-maintainer of readme_renderer.
[20:57:09] <thea> We'll also need to cut a release after those two are merged. I'll draft the PR once we get those in.
[21:01:03] <sumanah> thea: I have a release checklist for Twine that you are welcome to tweak and use for readme_renderer
[21:01:16] <sumanah> thea: https://twine.readthedocs.io/en/latest/contributing.html#making-a-new-release
[21:38:48] <thea> Thank you, dstufft! One last PR for readme_renderer: https://github.com/pypa/readme_renderer/pull/72
[21:39:52] <thea> once that's in, I'll cut the release and send a PR to warehouse to update it's version. Then we should be good to test GFM readmes. :D