Any chance you can add a test showing that the entry point works? Not sure if that's doable without adding pkgconfig-pypi as a test dependency.

I think we'll be using this new entrypoint in a CI job in gh-26574, so a dedicated test here may not be the best way of spending time. @FFY00 please correct me if I am wrong there.

That gh-26574 PR is pretty small - in case the issue we ran into there is fully fixed, please feel free to fold those changes into this PR.

EDIT: oops, wrong branch checked out

It looks like this is working, but I did notice something a little weird when I tried testing. It looks like if you use pkgconf.get_pkg_config_path() before importing NumPy, then import NumPy, the module is broken:

goldbaum at Mac in ~/Documents
○  python
Python 3.13.1 experimental free-threading build (main, Dec 10 2024, 14:07:41) [Clang 16.0.0 (clang-1600.0.26.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkgconf
>>> list(pkgconf.get_pkg_config_path())
['/Users/goldbaum/.pyenv/versions/3.13.1t/lib/python3.13t/site-packages/numpy/_core/lib/pkgconfig']
>>> import numpy
>>> numpy.__version__
Traceback (most recent call last):
  File "<python-input-3>", line 1, in <module>
    numpy.__version__
AttributeError: module 'numpy' has no attribute '__version__'
>>> quit

goldbaum at Mac in ~/Documents
○  python
Python 3.13.1 experimental free-threading build (main, Dec 10 2024, 14:07:41) [Clang 16.0.0 (clang-1600.0.26.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> import pkgconf
>>> list(pkgconf.get_pkg_config_path())
['/Users/goldbaum/.pyenv/versions/3.13.1t/lib/python3.13t/site-packages/numpy/_core/lib/pkgconfig']
>>> numpy.__version__
'2.3.0.dev0+git20250122.deb4bf3'

That seems like a bug in the pkgconf-pypi project though and probably unrelated to merging this.

Yeah, I don't think we really need a test, defining an entrypoint is very low-risk. If anything, what could make sense is making sure its value is correct, for the .pc file path.

I added a test to check the entrypoint. While I was at it, I also refactored a bit the test_configtool helpers to make them a bit more reliable, and moved them to numpy.testing.

It looks like this is working, but I did notice something a little weird when I tried testing. It looks like if you use pkgconf.get_pkg_config_path() before importing NumPy, then import NumPy, the module is broken:

That must have to do with our lazy loading, which we need to do to resolve the path of the module specified in the entrypoint without actually executing the module, in case that raises an exception. I'll look into it.

I believe the CI failure is unrelated, could someone trigger a re-run of the job? Thanks!

I believe the CI failure is unrelated, could someone trigger a re-run of the job? Thanks!

I re-ran it now. It is very likely related though - that's the one job that uses an editable install and builds extension modules with f2py, so I think your tweaks to determining IS_EDITABLE for the test suite are responsible.

Alright, everything's good now 😅

No worries, this did highlight some un-engornomic aspects of the importlib.metadata API (python/importlib_metadata#510, python/importlib_metadata#511), which was helpful.

The test_core_shims_coherence failure was due to the entrypoint lookup importing namespace packages, like numpy._core.lib.pkgconfig, which do not contain any code, so we don't care about them in the test.

The IS_INSTALLED workaround is very specific to this project, as environment.yml includes scipy for the docs, which pulls numpy, and then spin installs the project directly using Meson, which doesn't install metadata, so we do find the metadata for a numpy distribution, but it's the one from the base environment 🙃

@FFY00 you're adding an unconditional test dependency here, which is undesirable. Was the old method to determine IS_EDITABLE silently broken without us noticing? If not, what's the problem with continuing to use it?

The test_core_shims_coherence failure was due to the entrypoint lookup importing namespace packages, like numpy._core.lib.pkgconfig, which do not contain any code, so we don't care about them in the test.

If it's helpful to make it not a namespace package by adding an extra __init__.py, that'd be fine.

@FFY00 you're adding an unconditional test dependency here, which is undesirable. Was the old method to determine IS_EDITABLE silently broken without us noticing? If not, what's the problem with continuing to use it?

It depends on meson-python implementation details, and is incorrectly true if the environment prefix contains "editable" anywhere.

The unconditional test dependency is only on older Python versions, so it's temporary. It could be worked around by reading direct_url.json manually, but I generally prefer against that kind of fix as it introduces complexity and creates nontrivial future work. The importlib_metadata backport dependency will go away in a couple versions, and all we have to do is remove the version check. That said, if you prefer to work around the missing importlib.metadata API on older versions, I can do that, it's not a problem.

If it's helpful to make it not a namespace package by adding an extra __init__.py, that'd be fine.

No, we explicitly don't want those modules to show in test_core_shims_coherence, which tests if we re-export everything from numpy._core.

It depends on meson-python implementation details, and is incorrectly true if the environment prefix contains "editable" anywhere.

Yes I know, that's fine. Those are pretty minor downsides that don't matter in practice (and in case meson-python changes, is easy to fix up), so I'd much prefer not to add a dependency - that is very costly, since it affects not only CI but pretty much all distro packagers as well as contributors.

I'd be okay with an optional test dependency, but keeping the fallback to the current method is necessary instead of failing outright.

I backported importlib.metadata.Distribution.origin, which I think is less confusing to read than keeping the old check. Let's see if the CI is happy.

The CI seems to be happy now.

I trust you to know the packaging details here better than I do.

Packaging-wise, this only adds metadata, so it's a very low-risk change when it comes to the NumPy project itself ¹. They only affect the usage of the pkgconf package, which hasn't seen much adaption yet, so very low risk for any breakage of any kind. Adoption is we are attempting to bootstrap here, starting with NumPy providing the necessary metadata, and going on from there. Even within the pkgconf package context, the metadata we are exposing here is pretty low-risk — we are just pointing to the Python package containing the .pc file.

It's technically a new feature so I think it needs a release note.

Ah, yes, it definitely makes sense mentioning this in the release notes.

Also this is not your fault and it's not incumbent on you to fix in this PR, but it looks the only place numpy-config is documented is in the release notes. Maybe we could add a note to the docstring for np.show_config? Or give it its own page somewhere?

I am happy to do this, but maybe it'd be better to do it in a separate PR? So that we can discuss its documentation details without impacting the pkgconf entrypoints implementation.

I am happy to do this, but maybe it'd be better to do it in a separate PR?

Sounds great! I'm going to merge this now.