The way license appear on PyPi seems wrong

[jeandet]

I'm not sure if this is the expected behavior but setting license = {file="COPYING"} and "License :: OSI Approved :: GNU General Public License v3 (GPLv3)" doesn't work as expected for example with flit:
https://github.com/SciQLop/PyISTP/blob/main/pyproject.toml
I get on PyPi:

---

While with mesonpy:
https://github.com/SciQLop/CDFpp/blob/main/pyproject.toml
I get on PyPi:

---

BTW you get the same on PyPi:

---

This seems more related to mesonpy than PyPi I think.

[rgommers]

This is similar to what I asked in gh-88.

We got it working in SciPy: https://pypi.org/project/scipy/. You could have a look at SciPy's pyproject.toml.

[jeandet]

@rgommers indeed pretty close, thank you for your precious help! I've looked into scipy pyproject.toml it looks almost exactly like mine, reading #88 I feel like you do something manually but can't figure out what and how exactly. Do you override the license file during dist process? Is this related to the [tool.doit] section?

[rgommers]

Ugh, I have to retract the "we got it working" I'm afraid. I downloaded the sdist, and the License field there is not matching what is shown on PyPI. For the 1.9.0 release we actually built the sdist with meson-python and the wheels with numpy.distutils, because we didn't get the wheel build CI machinery updated in time. It looks to me like PyPI took the license info from the first wheel that was uploaded, and not from the sdist.

Is this related to the [tool.doit] section?

No, that's completely unrelated.

[jeandet]

Ah, ok, it makes sense then. Thank you :).

[rgommers]

So gh-88 solved including the license file as a file in the sdist/wheel. It did not solve how the License field appears on PyPI. It's unclear to me how exactly PyPI goes from License: BSD in PKG-INFO of a wheel or sdist to License: BSD License (BSD) shown in the Meta section in the left sidebar. Whatever it is, PEP 621 doesn't seem all that helpful here.

[jeandet]

I've looked into PKG-INFO files generated by flit and mesonpy I think it comes from this:

with mesonpy:

Metadata-Version: 2.1
Name: pycdfpp
Version: 0.3.4-5-g35b11ff
Summary: A modern C++ header only cdf library
Home-page: https://github.com/SciQLop/CDFpp
Author-Email: Alexis Jeandet <alexis.jeandet@member.fsf.org>
License: GNU GENERAL PUBLIC LICENSE
                              Version 3, 29 June 2007
        
            An easy to use ISTP loader package.
            Copyright (C) 2022  Alexis Jeandet
        
            This program is free software: you can redistribute it and/or modify
            it under the terms of the GNU General Public License as published by
            the Free Software Foundation, either version 3 of the License, or
            (at your option) any later version.
        
            This program is distributed in the hope that it will be useful,
            but WITHOUT ANY WARRANTY; without even the implied warranty of
            MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
            GNU General Public License for more details.
        
            You should have received a copy of the GNU General Public License
            along with this program.  If not, see <http://www.gnu.org/licenses/>.
        
        Also add information on how to contact you by electronic and paper mail.
        
          You should also get your employer (if you work as a programmer) or school,
        if any, to sign a "copyright disclaimer" for the program, if necessary.
        For more information on this, and how to apply and follow the GNU GPL, see
        <http://www.gnu.org/licenses/>.
        
          The GNU General Public License does not permit incorporating your program
        into proprietary programs.  If your program is a subroutine library, you
        may consider it more useful to permit linking proprietary applications with
        the library.  If this is what you want to do, use the GNU Lesser General
        Public License instead of this License.  But first, please read
        <http://www.gnu.org/philosophy/why-not-lgpl.html>.
Classifier: Development Status :: 2 - Pre-Alpha
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: GNU General Public License v3 (GPLv3)
Classifier: Natural Language :: English
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.7
Classifier: Programming Language :: Python :: 3.8
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Project-URL: Homepage, https://github.com/SciQLop/CDFpp
Requires-Python: >=3.7
Requires-Dist: numpy
Description-Content-Type: text/markdown
...

While with flit:

Metadata-Version: 2.1
Name: pyistp
Version: 0.1.3
Summary: An easy to use ISTP loader package.
Keywords: satellite,plasma-physics,nasa-data,amda,cdpp,CDF
Author-email: Alexis Jeandet <alexis.jeandet@member.fsf.org>
Maintainer-email: Alexis Jeandet <alexis.jeandet@member.fsf.org>
Requires-Python: >=3.7
Description-Content-Type: text/x-rst
Classifier: Development Status :: 4 - Beta
Classifier: Intended Audience :: Science/Research
Classifier: License :: OSI Approved :: GNU General Public License v3 (GPLv3)
Classifier: Natural Language :: English
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.7
Classifier: Programming Language :: Python :: 3.8
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Requires-Dist: pycdfpp
Project-URL: homepage, https://github.com/SciQLop/PyISTP
...

Looks like it works better when License key isn't there, then PyPi seems to look into Classifier: License.

[jeandet]

Note that this could change with flit doing like mesonpy if this gets merged :/ pypa/flit#537

[FFY00]

@di could you advise on the correct path forward?

[di]

Here's how PyPI uses these fields: https://github.com/pypi/warehouse/blob/39daea188d2e1e6494c50753cd48cb5a8da3e8c4/warehouse/packaging/views.py#L111-L123

The fact that the entire license is being displayed when built with meson makes me think that the metadata is not being written correctly, as PyPI should only be displaying the first line of the file.

[rgommers]

as PyPI should only be displaying the first line of the file.

That seems like a regression too. The first line is typically copyright info, for example for SciPy:

Copyright (c) 2001-2002 Enthought, Inc. 2003-2022, SciPy Developers.

Why not let the classifier take precedence if it exists? Until we get SPDX license expressions, that seems like the only reasonable behavior here.

[di]

Because, historically, when someone specifies the License field, they wanted to see that value displayed on PyPI. Per the core metadata spec, License is supposed to be used instead of classifiers:

Text indicating the license covering the distribution where the license is not a selection from the “License” Trove classifiers.

But in practice, people tend to specify both. Generally, providing multiple lines for License is a configuration mistake, so instead of dropping an entire file in the sidebar, PyPI just displays the first line, which is usually the name of the license (but isn't guaranteed to be).

[rgommers]

Generally, providing multiple lines for License is a configuration mistake,

PEP 621 says to provide the license file (from which the full text contents are then taken), or the license text itself: https://peps.python.org/pep-0621/#license. So hardly a mistake I'd think?

so instead of dropping an entire file in the sidebar, PyPI just displays the first line, which is usually the name of the license (but isn't guaranteed to be).

It seemed to me that the behavior you describe was supposed to be superseded by PEP 621. It would be quite odd that to get the correct behavior, one must not use the license field in PEP 621 (which should be the place for project metadata), but instead use a trove classifier. It looks like this interaction was missed in PEP 621 review?

And if this was thought about, then PEP 621 should say something explicitly about this I'd think?