Add support for file objects to load_registry()

[remram44]

This makes it possible to pass a file object to load_registry(), opened either in binary or text mode.

My main reason for this is to support passing pkg_resources.resource_stream() to it, which is the preferred way of using data files from the package (it will allow your package to be "zip-safe" though that doesn't matter as much those days).

This could be updated:

pooch/doc/usage.rst

Line 461 in 9a1382d

GOODBOY.load_registry(os.path.join(os.path.dirname(__file__), "registry.txt"))

to this:

GOODBOY.load_registry(pkg_resources.resource_stream("plumbus", "registry.txt"))

Reminders

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst.
• Write detailed docstrings for all functions/methods.
• If adding new functionality, add an example to the docstring, gallery, and/or tutorials.

[remram44]

Alternatively there could be a separate method that does the load_registry(resource_stream(...)) in one go.

[remram44]

(fixed lint issues: ' -> ", fp -> fin)

[leouieda]

Ooh, this is new to me. Bookmarking for later use 🙂

[leouieda]

Thanks for adding this, Rémi 👍 We can add the pkg_resources line to the docs but it might be better to include it as an alternative or recommended way. It's not very straight forward for those not familiar with setuptools (I didn't know about resource_stream) and this is a good chance to introduce it.

[remram44]

We can add the pkg_resources line to the docs but it might be better to include it as an alternative or recommended way.

Are you asking for it to be alternative or recommended?

To be honest it is pretty weird to not use pkg_resources in this context, since the example shows creating a complete package, with a setup.py and package_data. There are also multiple ways in which the os.path code can fail, for example if you move it to a sub-package, it will break unless you update it with an extra dirname() (or if running from a ZIP, os.path will construct paths inside the ZIP).

[leouieda]

Are you asking for it to be alternative or recommended?

Sorry, my comment wasn't clear. We should definitely recommend this as the preferred approach since it's the correct thing to do (we should probably do it internally as well :). But we should probably acknowledge that the other approach exists and why it's best to do it this way. This can be done in another PR as it's not directly related to this.

Merging this one in since it seems to be complete and all tests pass. Thanks! I always learn some new things from your PRs 🙂