CI: xlrd PendingDeprecationWarning

[jbrockmendel]

https://travis-ci.org/pandas-dev/pandas/jobs/427910477

E           AssertionError: Caused unexpected warning(s): [('PendingDeprecationWarning', PendingDeprecationWarning("This method will be removed in future versions.  Use 'tree.iter()' or 'list(tree.iter())' instead.",), '/home/travis/miniconda3/envs/pandas/lib/python2.7/site-packages/xlrd/xlsx.py', 246), ('PendingDeprecationWarning', PendingDeprecationWarning("This method will be removed in future versions.  Use 'tree.iter()' or 'list(tree.iter())' instead.",), '/home/travis/miniconda3/envs/pandas/lib/python2.7/site-packages/xlrd/xlsx.py', 292), ('PendingDeprecationWarning', PendingDeprecationWarning("This method will be removed in future versions.  Use 'tree.iter()' or 'list(tree.iter())' instead.",), '/home/travis/miniconda3/envs/pandas/lib/python2.7/site-packages/xlrd/xlsx.py', 246)].

[TomAugspurger]

https://github.com/python-excel/xlrd/issues/104

I wonder why this is failing now...

[dwt]

I think this might be the reason: https://github.com/python-excel/xlrd/issues/315

[inclusive-dev1]

The xlrd package has not made any progress on fixing this issue. I have not seen any response from a maintainer in the python-excel/xlrd#315 thread. Is there someone who could reach out to that team? Or if maintenance of xlrd is slowing down, is there an alternate dependency (or fork) that supports both xls and xlsx?

This issue was closed with a fix to skip that warning in the tests but perhaps it is time to look for a more long term solution?

We're forking our own at here, until the maintainer of this package passes the reins to us. Our own package also has a number of improvements.

UPDATE: The GitHub repo is here.

[dwt]

Uhm, am I blind or is there no link to a GitHub repo on the pypi page?

[inclusive-dev1]

Uhm, am I blind or is there no link to a GitHub repo on the pypi page?

Nope. We were blind and confused. The GitHub repo is at here.

We're actually still very uneasy about forking off like this. For now, the name is xlrdinc because we wanted to be known as the "Inclusive" group. Please help us find a better name for the fork.

Starting clean and official. Once we get a proper name for the fork, we want to reuse the original README.md completely, save for a pointer linking to xlrd repo; there's no way to GitHub-fork and still get our own Issue Tracking System. Also, we can't push a new version of xlrd package, so that part of the README.md will still need to be changed.

Core contributors. We're also hoping for core contributors to join us in the new fork. We're committed to maintaining the new fork on our own, but we're lonely folks and need good company.

[dwt]

There is current development to get old packages picked up, so maybe have a look at pypi/warehouse#1506 to see if there is a way to continue using the old package name even though the old maintainer is not contactable anymore. Still it would be best to collaborate with him. If he doesn't reply, maybe try to call him?

[inclusive-dev1]

There is current development to get old packages picked up, so maybe have a look at pypa/warehouse#1506 to see if there is a way to continue using the old package name even though the old maintainer is not contactable anymore.

We've created a PEP 541 name transfer request.

Still it would be best to collaborate with him. If he doesn't reply, maybe try to call him?

We would rather rely on a public communications channel (GitHub) to do the contacting. Publicly recorded and visible. We're sticklers for respecting privacy. :-P

May need entirely new project instead

Even if we do manage to get the maintainers back on board and active, there's also the issue of speed of development for us (our in-house use of xlrd and xlwt).

We could still use our own faster fork of xlrd, but we can no longer rely on distributing locally installed wheel binaries. I would imagine that users of xlrd would not want to rely on a locally installed wheel binary just to get timely updates to xlrd, so there's the possibility we may actually have to just create a new project that supersedes xlrd et al.

Still looking for a good name. So we're back to asking the community for a good package name. Once we get that, we'll do a proper GitHub repo (not GitHub-fork, so the community gets to file issues in new repo under our control), and create a proper PyPI package profile.

For now, we're reluctant to link to our GitHub project because we don't want users to think we just hijacked the xlrd project. The xlrdinc project remains an in-house tool until such time that we get a good name to set up a real open-source project.

[dwt]

Well, I don't mind you sticking to public communications, but it may pay to get the old maintainer to notice those first. Looking at the current state of affair of the xlrd project it sure seems that he is not monitoring his emails from that project, so trying to exclusively using those seems unnecessarily risky.

So maybe give him a call, to make sure he is aware that you are willing to put in the time to progress further with these projects is something you should rethink.

[cjw296]

You'd think about maybe trying on the python-excel mailing list?