Standardise on license_files, omit when possible?

Question

Standardise on license_files, omit when possible?

hugovk opened this issue 4 years ago · 9 comments

About:

adds license_file / license / license classifier if LICENSE exists

Newly released Setuptools 56.0.0 (changelog, docs, PR, issue) has deprecated license_file, and license_files should be used instead.

Further, if license_files is omitted, it defaults to LICEN[CS]E*, COPYING*, NOTICE*, AUTHORS*, matching the behaviour of bdist_wheel.

To simplify a project's config, I removed license_file = LICENCE from a project's setup.cfg, but then setup-cfg-fmt put it back :)

Should setup-cfg-fmt standardise license_file -> license_files?

And, if the value matches the glob pattern, should setup-cfg-fmt omit it completely?

Thanks!

Answer 1 · 2021-04-10T14:39:30.000Z

I know there's a duple somewhere, but this setting is too new to do generically -- maybe in a few years

Answer 2 · 2021-04-11T06:59:13.000Z

I understand that the glob thing is too new to implement right now but regarding the other request : There's a replacement for the deprecated option, isn't using license_files instead doable right now ? license_files has been supported in setuptools since november 2019 (in 42.0.0 pypa/setuptools#1767) and license_file has been deprecated in wheel for more than 2 years. pypa/wheel@59976ab.

Answer 3 · 2021-04-11T10:50:11.000Z

Yep, probably good to start getting projects moved over from the deprecated option to the supported one.

Answer 4 · 2021-04-11T14:11:06.000Z

2019 is significantly newer than any other date of support for declarative metadata: https://github.com/asottile/setup-py-upgrade#what-versions-of-setuptools--pip-does-the-output-work-with

Answer 5 · 2022-05-31T22:34:39.000Z

We could make it so setup-cfg-fmt could honor my pyproject.toml, which has

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

and thus emit license_files in my setup.cfg, and any other metadata as appropriate for the setuptools version. This seems like exactly the sort of problem that PEP 517/518 was designed to solve.

Would this make sense?

Answer 6 · 2022-05-31T22:35:45.000Z

no thanks, I don't want to get into the business of reading toml and parsing requirements specifiers

Answer 7 · 2022-06-12T11:45:24.000Z

2019 is significantly newer than any other date of support for declarative metadata: asottile/setup-py-upgrade#what-versions-of-setuptools--pip-does-the-output-work-with

The most recent date there is 2018-03-21.
setuptools v42.0.0 is from 2019-11-23.

Do you have a rough idea of when it might be acceptable to do the jump?

(When this was opened, 2018-03-21 was 36 months ago. Today, 2019-11-23 is 30 months ago, so perhaps in +6 months?)

Answer 8 · 2022-06-13T16:37:37.000Z

I tried to get some data on the setuptools version in each distro from repology.

Notably, centos 7's version of setuptools is 39.2.0, its EOL is 2024-06-30

List of distros/repos whose latest version of setuptools is older than 42.0.0

0: aosc
0.6rc9: gobolinux
0.6rc9: maemo_fremantle
0.6.10: centos_6
0.6.10: rosa_server_6_9
0.9.8: aixtoolbox
3.3: ubuntu_14_04
5.5.1: debian_8
5.5.1: devuan_1_0
18.3.2: opensuse_leap_42_3
18.6.1: rosa_2014_1
19.2: rosa_server_7_3
19.6.2: rosa_server_7_5
20.7.0: ubuntu_16_04
20.10.1: neurodebian_debian_8
20.10.1: neurodebian_debian_9
20.10.1: neurodebian_debian_unstable
20.10.1: neurodebian_ubuntu_16_04
22.0.5: slackware_14_2
22.0.5: slackware64_14_2
22.0.5: slackwarearm_14_2
27.2.0: openwrt_17_01_x86_64
32.3.1: aix_osp
33.1.1: astra_stable
33.1.1: debian_9
33.1.1: devuan_2_0
33.1.1: pardus_17
33.1.1: trisquel_7_0
33.1.1: trisquel_7_0_backports
33.1.1: trisquel_8_0
33.1.1: trisquel_8_0_backports
36.2.7: amazon_1
36.7.2: aur
37.0.0: fedora_26
37.0.0: fedora_27
38.4.1: opensuse_leap_15_0
38.5.1: rosa_2016_1
39.0.1: trisquel_9_0
39.0.1: ubuntu_18_04
39.1.0: alpine_3_8
39.2.0: centos_7
39.2.0: epel_6
39.2.0: scientific_7x
40.4.3: openeuler_20_03
40.4.3: slitaz_next
40.5.0: opensuse_leap_15_1
40.5.0: opensuse_leap_15_2
40.5.0: opensuse_leap_15_3
40.6.3: alpine_3_9
40.8.0: alpine_3_10
40.8.0: alt_p9
40.8.0: apertis_v2020
40.8.0: apertis_v2021
40.8.0: debian_10
40.8.0: deepin_unstable
40.8.0: fedora_28
40.8.0: devuan_3_0
40.8.0: fedora_29
40.8.0: fedora_30
40.8.0: pardus_19
40.8.0: pureos_amber
40.8.0: raspbian_oldstable
41.0.0: mageia_7
41.0.1: crux_34
41.0.1: openmandriva_4
41.2.0: rpmsphere
41.2.0: solus
41.6.0: fedora_31
41.6.0: fedora_32

Script I used

import requests
from typing import cast
from typing import Union
from typing import TypedDict
import dataclasses
import packaging.version
import collections


VersionType = Union[packaging.version.Version, packaging.version.LegacyVersion]


class Package(TypedDict, total=False):
    pep440version: VersionType
    version: str
    repo: str
    subrepo: str


@dataclasses.dataclass
class Repo:
    name: str
    packages: list[Package] = dataclasses.field(default_factory=list)

    def latest(self) -> VersionType:
        return max(pkg["pep440version"] for pkg in self.packages)


def main() -> int:
    resp = requests.get("https://repology.org/api/v1/project/python:setuptools")
    pkgs = cast(list[Package], resp.json())
    for pkg in pkgs:
        pkg["pep440version"] = packaging.version.parse(pkg["version"])
    repos_by_name = {}
    for pkg in pkgs:
        repo_name = pkg["repo"]
        if repo_name not in repos_by_name:
            repos_by_name[repo_name] = Repo(name=repo_name)
        repos_by_name[repo_name].packages.append(pkg)
    repos = sorted(repos_by_name.values(), key=lambda r: r.latest())
    target = packaging.version.Version("42.0.0")
    for repo in repos:
        if repo.latest() >= target:
            continue
        print(f"{repo.latest()}: {repo.name}")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

Answer 9 · 2022-06-13T17:10:54.000Z

Thanks, CentOS 7's version of virtualenv is 15.1.0, older than the existing requirement.

List of distros/repos whose latest version of virtualenv is older than 15.2

1.5.1: slitaz_next
1.7.1.2: trisquel_6_0
1.10.1: rosa_server_7_3
1.11.4: trisquel_7_0
1.11.4: ubuntu_14_04
1.11.6: debian_8
1.11.6: devuan_1_0
12.0.7: epel_6
13.1.2: opensuse_leap_42_3
13.1.2: rosa_2014_1
15.0.1: trisquel_8_0
15.0.1: ubuntu_16_04
15.1.0: scientific_7x
15.1.0: almalinux_8
15.1.0: alpine_3_8
15.1.0: alpine_3_9
15.1.0: amazon_1
15.1.0: amazon_2
15.1.0: apertis_v2020
15.1.0: apertis_v2021
15.1.0: astra_stable
15.1.0: centos_7
15.1.0: centos_8
15.1.0: centos_stream_8
15.1.0: debian_9
15.1.0: debian_10
15.1.0: deepin_unstable
15.1.0: devuan_2_0
15.1.0: devuan_3_0
15.1.0: epel_7
15.1.0: eurolinux_8
15.1.0: fedora_26
15.1.0: opensuse_leap_15_0
15.1.0: pardus_17
15.1.0: pardus_19
15.1.0: pureos_amber
15.1.0: raspbian_oldstable
15.1.0: rocky_8
15.1.0: rosa_server_7_5
15.1.0: slackbuilds
15.1.0: trisquel_9_0
15.1.0: ubi_8
15.1.0: ubuntu_18_04