-
Notifications
You must be signed in to change notification settings - Fork 68
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
The way license appear on PyPi seems wrong #129
Comments
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 |
@rgommers indeed pretty close, thank you for your precious help! I've looked into scipy |
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
No, that's completely unrelated. |
Ah, ok, it makes sense then. Thank you :). |
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 |
I've looked into PKG-INFO files generated by flit and mesonpy I think it comes from this: with mesonpy:
While with flit:
Looks like it works better when License key isn't there, then PyPi seems to look into |
Note that this could change with flit doing like mesonpy if this gets merged :/ pypa/flit#537 |
@di could you advise on the correct path forward? |
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. |
That seems like a regression too. The first line is typically copyright info, for example for SciPy:
Why not let the classifier take precedence if it exists? Until we get SPDX license expressions, that seems like the only reasonable behavior here. |
Because, historically, when someone specifies the
But in practice, people tend to specify both. Generally, providing multiple lines for |
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?
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 And if this was thought about, then PEP 621 should say something explicitly about this I'd think? |
We essentially punted on making significant changes here until PEP 639 is accepted. |
Hmm, so should we open a PR to add a warning in PEP 621 to not use the license field? It is odd that trying to follow the spec as it is written leads to such malformed behavior, and then hearing that "we punted" (not sure if that's PyPI maintainers, or PyPA, or ?). PEP 621 is Final after all, so clearly something is wrong here. |
@di Is there an issue somewhere for PyPI we can follow? Bokeh is getting bitten by this as well. I agree w/ @rgommers that there should be a warning. PEP 621 explicitly demonstrates |
Yes, it was cross-linked by github above but that isn't as obvious as it could be. The PyPI warehouse software tracked this as pypi/warehouse#12392 but it has now been closed via a commit that limits the license field to 100 characters in order to limit the damage that mishandling can do here. |
I have reopened that issue 👍 |
Did that just break our current way of including license files in the sdist (see gh-96)? |
It shouldn't have any effect on the wheel, but currently PyPI displays:
Now it will only display:
|
That's arguably worse .... now it looks like a non open source license. |
Sorry... I'm not sure where the "BSD License" comes from, it's not in the license file, so that is actually probably still there at the beginning. Does PyPI display both the license file and the classifier? 🤔 I was attempting to reverse-engineer what a future rollout of PyPI will do based on source code, obviously this is prone to inaccuracies because I have no idea how their code works. :P |
Indeed, it looks like PyPI was displaying, until yesterday: We'll see soon what it will do now, because SciPy 1.10.0rc1 will be out within the next 1-2 days. |
This seems to have been fixed in PyPI now. Here's what it looks like for https://pypi.org/project/pyistp/, which is the package @jeandet reported on in the issue description: Other packages I checked all look fine as well, so I'll close this issue. |
This also needs to be removed from documentation if it's working now: https://meson-python.readthedocs.io/en/latest/reference/limitations.html#license-field-on-pypi |
I think I'm still affected by this: see https://pypi.org/project/spead2/. It currently shows:
For convenience, here's the source pyproject.toml. |
@bmerry I believe that that is how it's supposed to look now. The original bug report here was about the full license text being shown and the whole sidebar being a mess as a result. Now PyPI cuts it off at Showing the SPDX classifier only will have to wait for PEP 639 to be accepted and implemented. |
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.
The text was updated successfully, but these errors were encountered: