Fields are missing when I pip show my Python package

[jakelevi1996]

OS version

Windows 10

Python version

Python 3.7.6

Pip version

23.1.2

Guide link

https://packaging.python.org/tutorials/packaging-projects

Problem description

(see related Stack Overflow question I asked here)

I recently uploaded my first Python package to PyPI. The relevant parts of pyproject.toml are defined as follows (full file available here):

[build-system]
requires = ["setuptools>=61.0"]
build-backend = "setuptools.build_meta"

[project]
name = "jutility"
version = "0.0.4"
license = {text = "MIT License"}
authors = [
    {name = "Jake Levi", email = "[email protected]"},
]

# ...

[project.urls]
homepage = "https://github.com/jakelevi1996/jutility"

After installing this package with the command python3 -m pip install -U jutility, I run the command python3 -m pip show jutility, and get the following output:

Name: jutility
Version: 0.0.4
Summary: Collection of Python utilities intended to be useful for machine learning research and experiments
Home-page: 
Author: 
Author-email: Jake Levi <[email protected]>
License: MIT License
Location: /usr/local/lib/python3.10/dist-packages
Requires: matplotlib, numpy, Pillow
Required-by: 

Notably, the Home-page and Author fields are empty in the output from pip show, although they seem to be defined in pyproject.toml.

How should I change pyproject.toml to make these fields display properly in the pip show output?

Version-wise, I built and uploaded these packages to PyPI on my Windows 10 PC with Python 3.7.6, but I also tried downloading and installing this package and displaying the pip show output from a Google Colab notebook with Python 3.10.11. The package works completely as expected in the Colab notebook, but I get the same pip show output with empty Home-page and Author fields. I'd just like to know what I need to change in order to get these fields to display properly.

Error message

No response

[jakelevi1996]

I fixed the issue by deleting all but the first 3 lines of pyproject.toml, so that pyproject.toml looks like this:

[build-system]
requires = ["setuptools>=61.0"]
build-backend = "setuptools.build_meta"

I then added the following configuration to setup.cfg (thank you to @Ratul Hasan for the suggestion):

[metadata]
name = jutility
version = 0.0.8
author = Jake Levi
author_email = [email protected]
description = Collection of Python utilities intended to be useful for machine learning research and experiments
long_description = file: README.md
long_description_content_type = text/markdown
license = MIT License
license_files = LICENSE
url = https://github.com/jakelevi1996/jutility
project_urls =
    Documentation   = https://github.com/jakelevi1996/jutility
    Source Code     = https://github.com/jakelevi1996/jutility
    Bug Tracker     = https://github.com/jakelevi1996/jutility/issues

[options]
python_requires = >=3.7
install_requires =
    matplotlib>=3.5.3
    numpy>=1.21.6
    Pillow>=9.5.0

I now get the following output from python3 -m pip show jutility, as desired:

Name: jutility
Version: 0.0.8
Summary: Collection of Python utilities intended to be useful for machine learning research and experiments
Home-page: https://github.com/jakelevi1996/jutility
Author: Jake Levi
Author-email: [email protected]
License: MIT License
Location: /usr/local/lib/python3.10/dist-packages
Requires: matplotlib, numpy, Pillow
Required-by: 

[jakelevi1996]

As a follow-up question, may I ask why setup.cfg files are not mentioned in the Packaging Python Projects tutorial, and why instead the tutorial walks through placing all the configuration in pyproject.toml, when the setup.cfg syntax is arguably nicer, and appears to integrate more smoothly with pip (not leaving pip show fields blank, as I described in the issue)? I don't really see the benefit of the approach described in the tutorial.

[henryiii]

This was discussed in PEP 621. Author and Author-Email do not scale to multiple authors, so the non-optional Author-Email field is used with the name <email> format (Author has always been optional). And Home-page can be specified by the the more general, newer (PEP 345) Project-URL field, so it's also expected to be empty. The goal is to avoid multiple places to specify the same thing ("redundant and confusing", according to the PEP).

FYI, this also includes License. While the original plan (in 2001, PEP 241) was to have a short string here for the license, by 2003 (PEP 314) is it specified via Classifiers, which correctly support specific licenses and multiple licenses, and this field is only there to allow text describing deviations from some known license. So you should not fill this in, and use Trove classifiers, unless you are using a non-standard license.

The problem is not the filling of the fields, but with pip show. That really needs to be updated to handle the current format better. I'm guessing the main issue might be worries about breaking anyone parsing the output of pip show? That's a wild guess, though, it might just be no one has updated it yet. No one should be parsing that output. :)

setup.cfg is an old file format that is no longer needed. It's only for setuptools, as well, while the pyproject.toml configuration works with many backend - setuptools>62, hatchling, flit-core, pdm-backend, scikit-build-core, meson-python, maturin, enscons, whey, and trampolim, for example.

Edit: looks like "no one has done it yet" is likely the correct answer:

• Show 'home-page' project URL when Home-Page metadata value is not set pip#11221
• Should pip include Project-URLs in show output without verbose mode pip#11138

For example.

[jakelevi1996]

• Thanks for your reply @henryiii
• I guess for me, it sounds like the optimal situation would be that all of the fields in pip show can be configured from pyproject.toml, and that the Packaging Python Projects tutorial explains what needs to be added to pyproject.toml in order to configure each of those fields (as mentioned in the first post above, currently the tutorial doesn't explain how to configure the Home-page and Author fields)
• As someone who's new to packaging Python projects, it doesn't matter to me too much how everything "should" work, other than that everything should be reasonably convenient and well-documented
• Even if pyproject.toml technically "shouldn't" configure the Home-page and Author fields of pip show, as someone who's new to packaging Python projects, when I see that prominent packages such as numpy and matplotlib display those fields in pip show, I'll naturally want to figure out how to configure those fields in my own package
• If I could configure everything from pyproject.toml then I'd happily get rid of setup.cfg (which I didn't use in the first place, and only added because it could easily fill in pip show fields that I couldn't work out how to fill in from pyproject.toml)

[henryiii]

The solution is to change pip show, not to add back deprecated and duplicated fields. FYI, numpy is switching to a PEP621 backend, so it will be dropping those fields from pip show soon. And most people aren't looking at pip show, they are looking at PyPI (which is better updated for changes in the ecosystem, though not perfect).

FYI, try pip show on wheel (0.40+), build (0.10+), or packaging (23+), and you'll see the same blank fields. It's not a problem with the standards (which are specified in PEPs and were the result of extensive debate and revisions), it's a problem with pip show (which is a single package).

[jakelevi1996]

Fair enough, changing pip show would also work.

Locally I currently have Python 3.7.6 (still haven't got round to updating it or had a specific need to), wheel 0.38.4, build 0.10.0, and packaging 23.1, so maybe this explains why those fields are not blank for me

[jakelevi1996]

So I gather that the Author field in pip show is deprecated, but is the Home-page field not deprecated? I'm still confused about how I would display it from pyproject.toml. PEP 345 suggests either

Home-page: http://www.example.com/~cschultz/bvote/

Or

Project-URL: Bug Tracker, https://github.com/pypa/setuptools/issues
Project-URL: Documentation, https://setuptools.readthedocs.io/
Project-URL: Funding, https://donate.pypi.org

But all of these are in a different format to

[project.urls]
"Homepage" = "https://github.com/pypa/sampleproject"

Suggested by the Packaging Python Projects tutorial, which has the key wrapped in double quotes, and = as a separator rather than : (so additionally I'm not sure if the "Homepage" key should be updated in the tutorial to Home-page or Project-URL).

It seems to me as someone who is new to Python packaging like there is not just inconsistency between PEP 345 and pip show, but also between those 2 and the Packaging Python Projects tutorial

[pfmoore]

It's a change in recommended practice, which isn't reflected in the output of pip show (yet). Personally, I dislike the fact that Home-Page is no longer recommended (and is not supported by PEP 621) because - at least from what I recall - PyPI displays the home page specially. But my preference isn't likely to change anything.

Edit: looks like "no one has done it yet" is likely the correct answer:

Yes, probably combined with "no one has the stomach to work out what backward compatibility issues we need to consider" 🙁

[henryiii]

PEP 345 is showing the METADATA format, which is sort of YAML like (technically, it's based on the email module IIRC?), which is not related to the TOML format. Your build backend (setuptools, hatching, flit-core, etc) will convert the standard TOML fields defined in PEP 621 into METADATA. There isn't a field for Home-Page or Author, and there's not really one for License either (the PEP 621 definition didn't match the METADATA definition, and is being revised in PEP 639).

pip show isn't supposed to have backward compatibly issues, since you aren't supposed to parse the output, but rather use METADATA yourself if you want to process it, but yes, I'm sure someone does. 🤦