rpms / python-tomli

Clone
Source Code
GIT

#21 [DO NOT MERGE] Initial package for RHEL 9
Closed 6 months ago by churchyard. Opened 6 months ago by churchyard.
rpms/ churchyard/python-tomli rhel9  into  epel9

file added
+1 
@@ -0,0 +1,1 @@ 
 

+ 1

file modified
+4 
@@ -2,3 +2,7 @@ 
 

  /1.1.0.tar.gz
 

  /1.2.1.tar.gz
 

  /1.2.2.tar.gz
 

+ /1.2.3.tar.gz
 

+ /2.0.0.tar.gz
 

+ /2.0.1.tar.gz
 

+ /python-tomli-2.0.1.tar.gz

file added
+7 
@@ -0,0 +1,7 @@ 
 

+ --- !Policy
 

+ 

+ product_versions:
 

+   - rhel-9
 

+ decision_context: osci_compose_gate
 

+ rules:
 

+   - !PassingTestCaseRule {test_case_name: osci.brew-build.tier0.functional}

file added
+11 
@@ -0,0 +1,11 @@ 
 

+ discover:
 

+   - name: Smoke-tests
 

+     how: shell
 

+     tests:
 

+     - name: python-import-test
 

+       test: python3 -c 'import tomli'
 

+       require:
 

+       - python3-tomli
 

+       duration: 2m
 

+ execute:
 

+   how: tmt

file modified
+20 -56 
@@ -1,27 +1,23 @@ 
 

- # This package buildrequires flit_core to build the wheel, but flit_core requires tomli.
 

- # To bootstrap, we copy the files to appropriate locations manually and create a minimal dist-info metadata.
 

- # Note that as a pure Python package, the wheel contains no pre-built binary stuff.
 

- # When bootstrap is enabled, we don't run tests either, just an import check.
 

- %bcond_with     bootstrap
 

- 

  Name:           python-tomli
 

- Version:        1.2.2
 

- Release:        2%{?dist}
 

+ Version:        2.0.1
 

+ Release:        5%{?dist}
 

  Summary:        A little TOML parser for Python
 

  

  License:        MIT
 

  URL:            https://pypi.org/project/tomli/
 

- Source0:        https://github.com/hukkin/tomli/archive/refs/tags/%{version}.tar.gz
 

+ Source0:        https://github.com/hukkin/tomli/archive/%{version}/%{name}-%{version}.tar.gz
 

+ 

+ # Upstream tomli uses flit, but we want to use setuptools on RHEL 9.
 

+ # This a downstream-only setup.py manually created from pyproject.toml metadata.
 

+ # It contains a @@VERSION@@ placeholder.
 

+ Source1:        tomli-setup.py
 

  

  BuildArch:      noarch
 

  BuildRequires:  python3-devel
 

  

- %if %{without bootstrap}
 

- # Upstream test requirements are in tests/requirements.txt,
 

- # but they're mixed together with coverage ones. Tests only need:
 

+ # The test suite uses the stdlib's unittest framework, but we use %%pytest
 

+ # as the test runner.
 

  BuildRequires:  python3-pytest
 

- BuildRequires:  python3-dateutil
 

- %endif
 

  

  %global _description %{expand:
 

  Tomli is a Python library for parsing TOML.
 
@@ -38,71 +34,39 @@ 
 

  

  %prep
 

  %autosetup -p1 -n tomli-%{version}
 

+ sed 's/@@VERSION@@/%{version}/' %{SOURCE1} > setup.py
 

+ rm pyproject.toml  # force the PEP 517 fallback build backend (setuptools)
 

  

  

- %if %{without bootstrap}
 

  %generate_buildrequires
 

  %pyproject_buildrequires -r
 

- %endif
 

  

  

  %build
 

- %if %{without bootstrap}
 

  %pyproject_wheel
 

- %else
 

- %global distinfo tomli-%{version}+rpmbootstrap.dist-info
 

- mkdir %{distinfo}
 

- cat > %{distinfo}/METADATA << EOF
 

- Metadata-Version: 2.2
 

- Name: tomli
 

- Version: %{version}+rpmbootstrap
 

- EOF
 

- %endif
 

  

  

  %install
 

- %if %{without bootstrap}
 

  %pyproject_install
 

  %pyproject_save_files tomli
 

- %else
 

- mkdir -p %{buildroot}%{python3_sitelib}
 

- cp -a tomli %{distinfo} %{buildroot}%{python3_sitelib}
 

- echo '%{python3_sitelib}/tomli/' > %{pyproject_files}
 

- echo '%{python3_sitelib}/%{distinfo}/' >> %{pyproject_files}
 

- %endif
 

  

  

  %check
 

  %py3_check_import tomli
 

- %if %{without bootstrap}
 

- # assert the properly built package has no runtime requires
 

- # if it does, we need to change the bootstrap metadata
 

- test -f %{buildroot}%{python3_sitelib}/tomli-%{version}.dist-info/METADATA
 

- ! grep '^Requires-Dist:' %{buildroot}%{python3_sitelib}/tomli-%{version}.dist-info/METADATA
 

  %pytest
 

- %endif
 

  

  

  %files -n python3-tomli -f %{pyproject_files}
 

  %doc README.md
 

  %doc CHANGELOG.md
 

- %license LICENSE
 

  

  

  %changelog
 

- * Fri Oct 29 2021 Miro Hrončok <mhroncok@redhat.com> - 1.2.2-2
 

- - Allow a bootstrap build without flit_core
 

- 

- * Wed Oct 27 2021 Petr Viktorin <pviktori@redhat.com> - 1.2.2-1
 

- - Update to version 1.2.2
 

- 

- * Wed Aug 18 2021 Petr Viktorin <pviktori@redhat.com> - 1.2.1-1
 

- - Update to version 1.2.1
 

-   - loading text (as opposed to binary) files is deprecated
 

- 

- * Thu Jul 29 2021 Petr Viktorin <pviktori@redhat.com> - 1.1.0-1
 

- - Update to version 1.1.0
 

-   - `load` can now take a binary file object
 

- 

- * Thu Jul 22 2021 Petr Viktorin <pviktori@redhat.com> - 1.0.4-1
 

- - Initial package
 

+ * Wed Mar 08 2023 Miro Hrončok <mhroncok@redhat.com> - 2.0.1-5
 

+ - Initial package for RHEL 9
 

+ - Resolves: rhbz#2175213
 

+ - Fedora+EPEL contributions by:
 

+       Maxwell G <gotmax@e.email>
 

+       Michel Alexandre Salim <salimma@fedoraproject.org>
 

+       Miro Hrončok <miro@hroncok.cz>
 

+       Petr Viktorin <pviktori@redhat.com>

file modified
+1 -1 
@@ -1,1 +1,1 @@ 
 

- SHA512 (1.2.2.tar.gz) = 460ad8ae9a342d82ef12911c0d0e246c1434a5d40d898e91f6c05bf37b7bf9921da05e004c36907d623a797a7a215c1c3faf3f9a2b940f3867b142847a188605
 

+ SHA512 (python-tomli-2.0.1.tar.gz) = a467f8d48cdbd7213bd9b6f85fd48ba142ab7c9656c40bb30785e1c4b37a9e29eaed420f183458ad20112baee8413ebbec87755332795c8f02235d1018c3aa5c

file added
+37 
@@ -0,0 +1,37 @@ 
 

+ import pathlib
 

+ from setuptools import setup
 

+ 

+ setup(
 

+     name="tomli",
 

+     version="@@VERSION@@",
 

+     description="A lil' TOML parser",
 

+     long_description=pathlib.Path("README.md").read_text(),
 

+     long_description_content_type="text/markdown",
 

+     packages=["tomli"],
 

+     package_dir={"": "src"},
 

+     package_data={"tomli": ["py.typed"]},
 

+     python_requires=">=3.7",
 

+     author="Taneli Hukkinen",
 

+     author_email="hukkin@users.noreply.github.com",
 

+     license="MIT",
 

+     classifiers=[
 

+         "License :: OSI Approved :: MIT License",
 

+         "Operating System :: MacOS",
 

+         "Operating System :: Microsoft :: Windows",
 

+         "Operating System :: POSIX :: Linux",
 

+         "Programming Language :: Python :: 3 :: Only",
 

+         "Programming Language :: Python :: 3.7",
 

+         "Programming Language :: Python :: 3.8",
 

+         "Programming Language :: Python :: 3.9",
 

+         "Programming Language :: Python :: 3.10",
 

+         "Programming Language :: Python :: Implementation :: CPython",
 

+         "Programming Language :: Python :: Implementation :: PyPy",
 

+         "Topic :: Software Development :: Libraries :: Python Modules",
 

+         "Typing :: Typed",
 

+     ],
 

+     keywords=["toml"],
 

+     project_urls={
 

+         "Homepage": "https://github.com/hukkin/tomli",
 

+         "Changelog": "https://github.com/hukkin/tomli/blob/master/CHANGELOG.md",
 

+     },
 

+ )

Note for reviwers

There is a git conflict here because it was easier to start the work on Rawhide(ish) rather than EPEL 9.
The conflict is meaningless in RHEL context because there will be a new/distinct git history anyway.
Please consider only the Initial package for RHEL 9 commit and anything that follows for review.

rebased onto 73d3be3c454c9df3ef13d14a738d04c70091d6f2
6 months ago

rebased onto 5c18eb30d5c62ca37651d84c67ce18c63133551d
6 months ago

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/612843ea6f084a6e813d3f9425f6eccf

rpminspect says:

/usr/lib/python3.9/site-packages/tomli/py.typed removed from noarch

Will make sure it's added.

1 new commit added

  • fixup! Initial package for RHEL 9
6 months ago

Pushed a fixup commit.

CentOS Stream 9 scratchbuild https://kojihub.stream.centos.org/koji/taskinfo?taskID=2047373

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/f89110beaa55459b81cf3f6a8c47d1eb

Why not use the pyproject macros?

Why not use the pyproject macros?

I guess I could do that, if I patch/sed the build backend in pyproject.toml. Will try.

1 new commit added

  • fixup! Initial package for RHEL 9
6 months ago

1 new commit added

  • fixup! Initial package for RHEL 9
6 months ago

Pushed 2 fixups. One is inspired by the latest RHEL8 fixup, the other switches back to pyproject macros.

CentOS Stream 9 scratchbuild https://kojihub.stream.centos.org/koji/taskinfo?taskID=2047413

Build succeeded.
https://fedora.softwarefactory-project.io/zuul/buildset/2e6e2963d7b046dab084bc7252978fc4

rebased onto cb0de74
6 months ago

Squashed and rebased on top of rawhide^1. Fixups are preserved in https://src.fedoraproject.org/fork/churchyard/rpms/python-tomli/commits/rhel9-fixups in case anybody wants to inspect them.

CentOS Stream 9 scratchbuild https://kojihub.stream.centos.org/koji/taskinfo?taskID=2047980

This now conflicts, but that doesn't really matter, because the RHEL 9 package will be imported without git history. The latest commit (and its position) is the only one to review. Unfortunately, Zuul does not know how to handle this, but that's OK.

1 new commit added

  • Add tmt gating plan
6 months ago
  • version="2.0.1",

I think you forgot to replace this with @@VERSION@@

1 new commit added

  • fixup! Initial package for RHEL 9
6 months ago
  • version="2.0.1",

I think you forgot to replace this with @@VERSION@@

Thanks. Fixed up.

Building python-tomli-2.0.1-5.el9.src.rpm for c9s-candidate
Created task: 2049336
Task info: https://kojihub.stream.centos.org/koji/taskinfo?taskID=2049336
Edited 6 months ago by churchyard

Why not change the release to 1?

My personal preference would be to have the setup.py added as a simple patch instead of a source file but I see you add the version dynamically as well. Not a blocker, but definitely it's more complex than I would prefer.

Why not change the release to 1?

To maintain the upgrade path from the epel9 package, this needs to be greater than 1, i.e. at least 2 (if we account for simple integers only). I could set it to 2 but decided to let it be as it.

If you think 2 would be better than 5, I can do that. But 1 is not enough.
Edited 6 months ago by churchyard

My personal preference would be to have the setup.py added as a simple patch instead of a source file but I see you add the version dynamically as well. Not a blocker, but definitely it's more complex than I would prefer.

What do you mean by "simple patch"? The patch would create the setup.py file, hence it would be the same as now but with extra pluses all over. Why would that be less complex?
Edited 6 months ago by churchyard

My personal preference would be to have the setup.py added as a simple patch instead of a source file but I see you add the version dynamically as well. Not a blocker, but definitely it's more complex than I would prefer.

What do you mean by "simple patch"? The patch would create the setup.py file, hence it would be the same as now but with extra pluses all over. Why would that be better?

Yes the patch would create the setup.py file and we do have a proper definition for patch files in the SPEC. I don't see adding something as a source file and hacking it inside the exploded sources as a clean solution.

My personal preference would be to have the setup.py added as a simple patch instead of a source file but I see you add the version dynamically as well. Not a blocker, but definitely it's more complex than I would prefer.

What do you mean by "simple patch"? The patch would create the setup.py file, hence it would be the same as now but with extra pluses all over. Why would that be better?

Yes the patch would create the setup.py file and we do have a proper definition for patch files in the SPEC. I don't see adding something as a source file and hacking it inside the exploded sources as a clean solution.

I consider maintaining a standalone setup.py source much easier (and cleaner) than a patch that adds it. Fore example, when I was hacking it, I could easily black it or check it for syntax errors. Extra source files added in addition to the upstream source tarball are not uncommon in RPM packages (e.g. a forgotten LICENSE file etc.). We obviously have a different opinion here, so if this isn't a blocker for you, I'd rather keep it as a Source.
Edited 6 months ago by churchyard

13 new commits added

  • Add tmt gating plan
  • Initial package for RHEL 9
  • Remove the bootstrap bcond
  • Remove incorrect python3-dateutil test BuildRequires
  • Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
  • spec nit: Fix SourceURL
  • Rebuilt for Python 3.11
  • Bootstrap for Python 3.11
  • Don't use `! ...` as a check
  • Fix %with bootstrap build, sources were moved to src/
  • Version 2.0.1
  • Update to 1.2.3
  • - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
6 months ago
  • version="2.0.1",

I think you forgot to replace this with @@VERSION@@

Thanks. Fixed up.

Squashed.

13 new commits added

  • Add tmt gating plan
  • Initial package for RHEL 9
  • Remove the bootstrap bcond
  • Remove incorrect python3-dateutil test BuildRequires
  • Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
  • spec nit: Fix SourceURL
  • Rebuilt for Python 3.11
  • Bootstrap for Python 3.11
  • Don't use `! ...` as a check
  • Fix %with bootstrap build, sources were moved to src/
  • Version 2.0.1
  • Update to 1.2.3
  • - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
6 months ago

My personal preference would be to have the setup.py added as a simple patch instead of a source file but I see you add the version dynamically as well. Not a blocker, but definitely it's more complex than I would prefer.

What do you mean by "simple patch"? The patch would create the setup.py file, hence it would be the same as now but with extra pluses all over. Why would that be better?

Yes the patch would create the setup.py file and we do have a proper definition for patch files in the SPEC. I don't see adding something as a source file and hacking it inside the exploded sources as a clean solution.

I consider maintaining a standalone setup.py source much easier (and cleaner) than a patch that adds it. Fore example, when I was hacking it, I could easily black it or check it for syntax errors. Extra source files added in addition to the upstream source tarball are not uncommon in RPM packages (e.g. a forgotten LICENSE file etc.). We obviously have a different opinion here, so if this isn't a blocker for you, I'd rather keep it as a Source.

Of course I understand the reasoning behind it. I'd just say it's unconventional in the majority of packages, as extra source files would usually be patches, CI related files, docs such as licenses and in some minority of cases, scripts that provide functionality not possible to do in %prep. Nevertheless as mentioned it's not a blocker and you can keep it as such. 

+ sed 's/@@VERSION@@/%{version}/' %{SOURCE1} > setup.py && rm pyproject.toml

Could you add a comment explaining that you're removing the pyproject.toml so the pyproject macros fallback to setuptools? This might not be clear to less experienced Python packagers.
Edited 6 months ago by gotmax23

+ sed 's/@@VERSION@@/%{version}/' %{SOURCE1} > setup.py && rm pyproject.toml

Could you add a comment explaining that you're removing the pyproject.toml so the pyproject macros fallback to setuptools? This might not be clear to less experienced Python packagers.

Done.

1 new commit added

  • Add a comment about rm pyproject.toml
6 months ago

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging src.fedoraproject.org/rpms/python-tomli for 21,528b315

Thanks! This looks good to me now. The unfortunate lack of flit-core is handled as cleanly as possible, and there are minimal changes from rawhide.

Pull-Request has been closed by churchyard
6 months ago
Metadata
None
No Tags
Changes Summary 7
+1
file added
.fmf/version
+4 -0
file changed
.gitignore
+7
file added
gating.yaml
+11
file added
plans.fmf
+20 -56
file changed
python-tomli.spec
+1 -1
file changed
sources
+37
file added
tomli-setup.py
Powered by Pagure 5.13.3
Documentation • File an Issue • About this Instance • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.