Issues with Conda distribution (when updating to `select` interface)

[chrisjsewell]

I just updated my package, to require importlib-metadata>=3.6 and fix the deprecation: DeprecationWarning: SelectableGroups dict interface is deprecated. Use select. (now using entry_points(group=group_name, name=entry_name)).

However, for some weird reason there is both:

• https://github.com/conda-forge/importlib_metadata-feedstock
• https://github.com/conda-forge/importlib-metadata-feedstock (archived)

So you can easily end up with:

importlib-metadata        4.0.1                    pypi_0    pypi
importlib_metadata        2.0.0                         1  

and then it seems that it can be undetermistic which version you end up importing,
leading to: TypeError: entry_points() got an unexpected keyword argument 'group'

I don't imagine I'll be the only one bitten by this, and kind of means if you have a Conda distribution you can't write code that assumes you are installing importlib_metadata>=3.6

[FFY00]

Actually, I would expect the importlib-metadata conda package to be always used, not the other way round, because importlib-metadata is the normalized version of the name. See https://www.python.org/dev/peps/pep-0503/#normalized-names. It seems like conda is not normalizing names before fetching the packages, so it should be a conda bug. AFAIK, no maintainer of this package has any connection to the conda-forge one.

cc-ing @marcelotrevisani @nehaljwani @nicoddemus, the conda-forge package maintainers

[chrisjsewell]

Note, in my case this was reported to me because someone was using the latest anaconda release (https://www.anaconda.com/blog/individual-edition-2020-11), which specifies jsonschema==3.2.0=py_2, that was yet to update importlib_metadata -> importlib-metadata (which it does in build 3: conda-forge/jsonschema-feedstock@6e8d357)
So running conda create -n test anaconda==2020.11, leads to:

  importlib-metadata conda-forge/noarch::importlib-metadata-2.0.0-py_1
  importlib_metadata conda-forge/noarch::importlib_metadata-2.0.0-1

Obviously I appreciate this is not "your fault", but that does not escape the fact that I actioned your deprecation warning and now have people complaining that my package is broken 😢 (so at least bares noting)

[jaraco]

Thanks for the report. I may have a solution for you. I recognize that while some packages can require importlib_metadata>=3.6, there are some cases (e.g. Python 3.5 or 2.7 support or compatibility with libraries that do, or intention to rely on importlib.metadata in Python 3.8 and 3.9) where a library might have an older importlib_metadata. In that case, backports.entry_points_selectable provides a compatibility wrapper. Perhaps that library could provide the compatibility you need until the conda packaging issue can be addressed.

[jaraco]

I would expect the importlib-metadata conda package to be always used, not the other way round, because importlib-metadata is the normalized version of the name. See https://www.python.org/dev/peps/pep-0503/#normalized-names. It seems like conda is not normalizing names before fetching the packages, so it should be a conda bug. AFAIK, no maintainer of this package has any connection to the conda-forge one.

To be sure, PEP 503 is the repository API, which means that from PyPI's perspective, importlib-metadata and importlib_metadata and ImporTlib.meTaDaTa are the same package name, but to the best of my knowledge, these constraints don't apply to package names generally, and in my opinion, packaging systems should honor the canonical package name (CherryPy and importlib_metadata and svg.charts) for presentation, but could (maybe should) de-duplicate based on normalized name. One thing a packaging system should never do is allow different versions of the same package to co-exist because only one of the names was normalized.

[jaraco]

See also #298 for other suggestions.

I don't think there's much this project can do, but if there's any way I can help, please ask.