Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add importlib-metadata, https URLs, remove setuptools #116

Merged
merged 3 commits into from Jan 20, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
5 changes: 3 additions & 2 deletions recipe/meta.yaml
Expand Up @@ -29,6 +29,7 @@ requirements:
- babel >=1.3
- docutils >=0.14,<0.18
- imagesize
- importlib-metadata >=4.4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have importlib-metadata on Python 3.10+? What happens when it is installed there? How does this interact with the builtin importlib.metadata when available?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have importlib-metadata on Python 3.10+? W

We do, back to e.g. linux-64/importlib-metadata-4.8.1-py310hff52083_1.tar.bz2

What happens when it is installed there

Nothing too freaky... it doesn't shadow the builtin (importlib.resources) or anything.

interact with the builtin importlib.metadata when available?

In the cases I've found, it looks like it will preferentially import from the separate package before trying the builtin.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting would have thought the builtin would be tried first. Have asked about that ( sphinx-doc/sphinx#10007 (review) ).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like it was answered... again, it's highly likely some package in a good-sized sphinx env is going to have the latest-and-greatest importlib because a lot of authors (pragmatically) can't be bothered to do pins, and i don't blame them. if it can't deal with the backport, then there are bigger problems, and if python keeps changing the API, this problem will basically never go away.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep agreed. Am use to seeing the other import order as the backport package is pretty static and eventually fades out of existence. There are of course exceptions like mock. Seems like this is more like mock than other backport packages.

If things become more fragmented, like the backport package should be used for certain Python versions and not others, we may need revisit dropping noarch.

Though hopefully things settle down eventually.

- jinja2 >=2.3
- packaging
- pygments >=2.0
Expand Down Expand Up @@ -56,7 +57,7 @@ test:
- sphinx-quickstart --version

about:
home: http://www.sphinx-doc.org
home: https://www.sphinx-doc.org
bollwyvl marked this conversation as resolved.
Show resolved Hide resolved
license: BSD-2-Clause
license_file: LICENSE
summary: Sphinx is a tool that makes it easy to create intelligent and beautiful documentation
Expand All @@ -66,7 +67,7 @@ about:
It was originally created for the new Python documentation, and it has excellent
facilities for the documentation of Python projects, but C/C++ is already supported
as well, and it is planned to add special support for other languages as well.
doc_url: http://www.sphinx-doc.org/en/stable/contents.html
doc_url: https://www.sphinx-doc.org/en/stable/contents.html
dev_url: https://github.com/sphinx-doc/sphinx

extra:
Expand Down