Log file Viewer

[01:25:58] <nedbat> this search for eventlet https://pypi.python.org/pypi?%3Aaction=search&term=eventlet&submit=search shows eventlet 0.18.0, but if I click it, it's a 404. Why is that?

[01:52:09] <agronholm> nedbat: these days pypi's index is always out of whack

[01:52:38] <agronholm> https://pypi.python.org/pypi/eventlet/0.18.2

[01:52:40] <nedbat> agronholm: meaning the kit is really gone, and it's the search results that are incorrect?

[01:52:53] <nedbat> agronholm: yes, i found the newer one, but removing older ones is bad form.

[01:53:07] <agronholm> the author has hidden the old version

[01:53:23] <agronholm> I doubt it's really gone, unless pip install with that specific version also fails

[01:53:35] <nedbat> it does, which is what brought me to pypi

[01:53:42] <nedbat> but: https://pypi.python.org/pypi/eventlet/0.17.4 this is there.

[01:54:03] <agronholm> as you may know authors can freely choose which versions are visible and which are not

[01:54:20] <nedbat> agronholm: yup.

[07:58:36] <ngaio> are most projects generating HISTORY.rst by hand or through some automated procedure tied to their code hosting? I have a legacy ChangeLog I'd like to convert to a HISTORY.rst

[07:59:08] <agronholm> ngaio: is HISTORY.rst a thing?

[07:59:19] <agronholm> I've never seen such a file

[07:59:54] <ngaio> agronholm, psutil has one, for example. And there is the project https://pypi.python.org/pypi/pyhistory/

[08:00:12] <mgedmin> I generate CHANGES.rst by hand

[08:00:39] <mgedmin> because I'm not disciplined enough with my commit messages to generate a good changelog from them in an automated way

[08:00:42] <agronholm> some kind of machine readable changelog is probably coming to python

[08:00:57] <agronholm> considering warehouse has a stub feature for that

[08:01:21] <mgedmin> there are tools (like zest.releaser) that help with updating version numbers and release dates in the changelog

[08:01:49] <agronholm> I use setuptools_scm for that

[08:01:58] <agronholm> ensures that git tags are up to date

[08:03:57] <ngaio> btw a couple of days ago I was saying how overwhelmed I was about figuring out setup.py / PyPi / distro packaging.... for the moment I'm just focusing on PyPi and getting my application running in a virtualenv, which has actually been incredibly helpful because I've noticed new versions of at least one library break my code

[08:04:37] <ngaio> if I'd stuck solely to making my code work with the python libraries my distro provides, I would never have figured that out

[08:08:36] <ngaio> wow zest.releaser looks quite comprehensive

[08:09:08] <mgedmin> it is a bit overwhelming

[08:11:06] <ngaio> I guess HISTORY.rst could just as easily be called CHANGES.rst !

[08:17:05] <mgedmin> many different naming conventions exist

[08:17:19] <mgedmin> I've seen CHANGELOG.rst, CHANGES.rst, NEWS.rst, and now HISTORY.rst

[08:17:30] <mgedmin> (plus I've seen .txt, .md, no extension at all ...)

[08:17:38] <mgedmin> CHANGES.rst is the most common name I've encountered

[08:18:07] <mgedmin> but that's because the Zope project conventions call it that, and I've touched many Zope packages

[08:24:48] <ngaio> CHANGES.rst it is then :-)

[11:13:19] <nedbat> btw, about eventlet: they removed 0.18.0 and 0.18.1, and are now getting an earful about it on GitHub....

[17:33:41] <ngaio> my end-user application is called 'Rapid Photo Downloader'. What would be a good package name? Is 'rpd' too terse? 'rapidphotodownloader' seems too long to me. Is something in between better, e.g. 'rapidphoto'?

[17:37:31] <ionelmc> ngaio: raphodo

[17:38:48] <ionelmc> catchy

[17:38:57] <ngaio> I think that's a Spanish name!

[17:41:44] <ngaio> Raphoto is a surname in South Africa

[17:48:12] <ionelmc> i guess you need to find it a firstname then

[17:49:03] <ngaio> Raphodo is also a South African surname, it turns out (not Spanish)

[17:49:26] <ngaio> ionelmc, obviously I have no idea what it means, but I like the sound of it - as you say, it's catchy

[17:49:56] <ionelmc> ngaio: RApid PHtoto DOwnloader

[17:50:28] <ionelmc> err, typos galore

[17:51:43] <ionelmc> only 32 google results, grab it while it's hot

[17:51:48] <ngaio> yes I got the derivation, it's better than any alternative I can think of, thanks. If I want to rename my project one day, it's a strong candidate

[20:20:20] <nanonyme> Hmm, are universal wheels always larger than tarballs?

[20:33:57] <njs> nanonyme: they're basically just zip files

[20:37:57] <Wooble> nanonyme: anecdotally, I seem to have 1 universal wheel that's smaller than the sdist for the same version.

[20:38:56] <Wooble> (they do *mostly* seem to be larger. I wondere if I did something horribly wrong. :) )

[20:39:23] <nanonyme> Oh, yeah, I guess wheel could in theory leave some files out that would be mandatory for reproducivity for sdist

[20:46:05] <Wooble> the version affected is old and I have doubts about whether anyone actually uses my module anyway so I guess I shouldn't worry :)

[20:47:51] <nanonyme> I'm not sure anyone uses my module either!

[20:47:56] <nanonyme> Well, I do :)

[20:48:12] <ngoldbaum> pypi download statistics are a sham anyway

[20:48:19] <ngoldbaum> because of e.g. travis

[20:48:30] <nanonyme> And because of caching PyPI mirrors

[20:49:01] <nanonyme> You get a burst of a couple of hundred downloads on any package, then it calms down

[20:49:06] <Wooble> I actually got a pull request last week so I guess at least 1 person uses it.

[20:49:16] <ngoldbaum> hmm, that makes me wonder if someone has written a "phone home" package that sense usage statistics (with an opt-in, natch)

[20:49:24] <ngoldbaum> s/sense/sends/

[20:49:54] <Wooble> I put google analytics on the docs, but that's inflated by weird referrer spam.

[20:51:09] <njs> ngoldbaum: https://github.com/njsmith/sempervirens

[20:52:13] <ngoldbaum> njs: woah, how astoundingly appropriate :)

[20:52:14] <njs> nanonyme: zips are generally larger than equivalent .tar.gz, because zip is bundle(gzip(file1), gzip(file2), ...), while .tar.gz is gzip(bundle(file1, file2, ...)). In the latter case the gzip step is able to notice redundancies between different files and compress them out.

[20:53:17] <njs> ngoldbaum: everyone is super excited about it but it is bottlenecked on people (e.g. me) having no spare bandwidth. pls help :-)

[20:53:34] <ngoldbaum> yeah, i'm looking over the ML now

[20:53:50] <ngoldbaum> projects invented at scipy always have a burst of energy then peter off...

[20:54:07] <nanonyme> njs, funny. So why was this format chosen for wheel?

[20:54:48] <njs> nanonyme: the trade-off is that zip files support efficient random access -- you can read a single file (e.g., the wheel metadata) without decompressing the whole thing.

[20:55:42] <njs> ngoldbaum: it wasn't exactly invented at scipy, there's been lots of slow work on e.g. getting the human subjects stuff sorted even before that. but yeah, there was a large impulse event around scipy, heavily damped :-)

[20:56:27] <ngoldbaum> this falls under the purview of an IRB?

[20:56:31] <ngoldbaum> i'm surprised by that

[21:00:22] <njs> ngoldbaum: it turns out not, if done carefully

[21:00:36] <njs> ngoldbaum: but we had to check

[21:00:48] <ngoldbaum> sounds like worthy due diligence

[21:01:02] <njs> ngoldbaum: https://github.com/njsmith/sempervirens/blob/master/docs/berkeley-irb-statement.md

[21:01:13] <ngoldbaum> anyway thanks for the link, i may try hacking on it, although my webapp foo is sadly lacking

[21:01:27] <ngoldbaum> would be very nice to have this for yt for when we apply for funding

[21:01:46] <njs> ngoldbaum: it's probably not at all clear from the repo what needs doing but if you're interested then we can chat or something and I can fill you in

[21:02:02] <ngoldbaum> ok, i'll shoot you an e-mail if i have time :)

[21:02:39] <njs> and yeah, exactly, everyone has this problem. We've actually had multiple program officers randomly emailing going "hey, just wanted to check if you needed any money to support that metrics project?"

[21:04:07] <njs> (unfortunately, money and time are not trivially interconvertible)

[21:04:21] <ngoldbaum> yes, although undergrads are surprisingly fungible

[21:05:55] <njs> yes, but unfortunately you cannot have undergrads write privacy policies, or (realistically) write software that needs to operate with perfect reliability and ~zero user impact on tens of millions of computers

[21:07:07] <ngoldbaum> true - all of this sounds distinctly non-fun but very useful

[21:07:19] <ngoldbaum> can NumFocus hire someone under contract to work on this?

[21:07:45] <njs> probably, but I could probably write the software in less time than it would take to find and hire someone :-)

[21:07:48] <njs> you see the problem :-)

[21:08:01] <njs> (unless you have a candidate in mind, in which case please do share :-))

[21:08:17] <ngoldbaum> not off-hand

[21:08:25] <ngoldbaum> well no one that isn't already working on other things anyway

[21:08:53] <ngoldbaum> this might be worth bringing up with the general python developer community

[21:09:07] <ngoldbaum> seems useful beyond scipy

[21:17:41] <njs> the current plan is to try to scope it to "open scientific software", because that's a coherent class that we can describe when asking for opt-in

[21:18:22] <njs> (the key idea of this plan is that there's a single opt-in presented for jupyter AND numpy AND yt AND ..., but that means we need to be able to communicate that clearly to users)

[21:18:38] <ngoldbaum> oh i see, interesting

[21:19:04] <ngoldbaum> i guess it's difficult/annoying for a new user to opt in every time they import a new package

[21:32:40] <njs> yeah, there's no way that numpy could realistically prompt the user -- we don't even know whether there is a user present.

[21:32:44] <njs> but jupyter can :-)