Migrated to pyproject.toml

Details:

* Added pyproject.toml with setuptools as build backend.

* Removed setup.py.

* Removed pywbem/_version.py from git tracking, because it is now
  dynamically created when building the distribution. Also, removed it
  from py_src_files, so t is no longer included in flake8, pylint, ruff
  checks.

* Removed inclusion of other requirements/constraints files with '-r' and '-c'
  because the dynamic support for dependencies in setuptools does not
  support these options. This has been replaced by ensuring that the
  "included" files are honored, in the Makefile.

* Renamed minimum-constraints.txt to minimum-constraints-develop.txt
  because it no longer includes minimum-constraints-install.txt

* Renamed .safety-policy-all.yml to .safety-policy-develop.yml to match
  its scope of only covering development dependencies.

* Removed support for building, installing and testing a cythonized
  version of pywbem, because the pyproject.toml approach dos not
  support that.

* Updated the release description in DEVELOP.md to no longer edit
  the version file, but to set tags. A new initial tag is now
  used on the master branch that makes setuptools-scm increase
  the correct version number. For consistency, that approach
  is also uused for stable branches.

Signed-off-by: Andreas Maier <andreas.r.maier@gmx.de>

.github/workflows/test.yml

@@ -143,11 +143,6 @@ jobs:
           }
           console.log(result)
           return result
-    - name: Select whether to run steps for cythonized archive
-      id: run_cythonized
-      if: "! startsWith(matrix.os, 'windows-') && (github.event_name == 'schedule' || startsWith(github.head_ref, 'release_'))"
-      run: |
-        echo "Running steps for cythonized archive"
     - name: Create local cache directory for Docker images
       # GitHub Actions has Docker only on Ubuntu
       if: startsWith(matrix.os, 'ubuntu-')
@@ -300,29 +295,6 @@ jobs:
         RUN_TYPE: ${{ steps.set-run-type.outputs.result }}
       run: |
         make perftest
-    - name: Build cythonized archive
-      if: steps.run_cythonized.outcome == 'success'
-      env:
-        PACKAGE_LEVEL: ${{ matrix.package_level }}
-        RUN_TYPE: ${{ steps.set-run-type.outputs.result }}
-      run: |
-        make buildc
-    - name: Install cythonized archive
-      if: steps.run_cythonized.outcome == 'success'
-      env:
-        PACKAGE_LEVEL: ${{ matrix.package_level }}
-        RUN_TYPE: ${{ steps.set-run-type.outputs.result }}
-      run: |
-        make installc
-    - name: Test cythonized archive
-      if: steps.run_cythonized.outcome == 'success'
-      env:
-        PACKAGE_LEVEL: ${{ matrix.package_level }}
-        RUN_TYPE: ${{ steps.set-run-type.outputs.result }}
-        # TODO: Remove -x option once tests succeed
-        TESTOPTS: "-x"
-      run: |
-        make testc
     - name: Run safety
       env:
         PACKAGE_LEVEL: ${{ matrix.package_level }}

.gitignore

@@ -36,6 +36,7 @@ mofparsetab.py
 _mofparsetab.py
 moflextab.py
 _moflextab.py
+pywbem/_version.py
 tests/runtests.log
 /tests/testtmp/
 /tests/schema/mof*/

.pyup.yml

@@ -35,7 +35,10 @@ requirements:
 #  - rtd-requirements.txt:
 #      pin: False
 #      update: insecure
-  - minimum-constraints.txt:
+  - minimum-constraints-install.txt:
+      pin: True
+      update: insecure
+  - minimum-constraints-develop.txt:
       pin: True
       update: insecure
 

.safety-policy-all.yml → .safety-policy-develop.yml

@@ -1,4 +1,4 @@
-# Safety policy file
+# Safety policy file needed for development
 # For documentation, see https://docs.pyup.io/docs/safety-20-policy-file
 #
 # Generally package vulnerabilites listed in the ignore-vulnerabilities
@@ -10,11 +10,6 @@
 #    vulnerability will remain ignored until such time as the versions of
 #    python that cannot support the required version of the package are no
 #    longer supported by pywbem.
-#
-# The way to see python version limitations for package versions
-#    as defined for pywbem is to filter the file minimum-constraints.txt
-#    for the package name. Multiple entries for same package name imply
-#    different minimum versions for different python releases.
 
 # Configuration for the 'safety check' command
 security:

.safety-policy-install.yml

@@ -10,11 +10,6 @@
 #    vulnerability will remain ignored until such time as the versions of
 #    python that cannot support the required version of the package are no
 #    longer supported by pywbem.
-#
-# The way to see python version limitations for package versions
-#    as defined for pywbem is to filter the file minimum-constraints.txt
-#    for the package name. Multiple entries for same package name imply
-#    different minimum versions for different python releases.
 
 # Configuration for the 'safety check' command
 security:

DEVELOP.md

@@ -77,15 +77,7 @@ local clone of the ``pywbem/pywbem`` Git repo.
         git pull
         git checkout -b release_${MNU}
 
-3.  Edit the version file:
-
-        vi pywbem/_version.py
-
-    and set the ``__version__`` variable to the version that is being released:
-
-        __version__ = 'M.N.U'
-
-4.  Edit the change log:
+3.  Edit the change log:
 
         vi docs/changes.rst
 
@@ -101,7 +93,7 @@ local clone of the ``pywbem/pywbem`` Git repo.
       add text for any known issues you want users to know about.
     * Remove all empty list items.
 
-5.  Edit the README file for PyPI:
+4.  Edit the README file for PyPI:
 
         vi README_PYPI.md
 
@@ -112,7 +104,7 @@ local clone of the ``pywbem/pywbem`` Git repo.
         .. _Documentation on RTD: https://pywbem.readthedocs.io/en/stable_M.N/
         .. _Change log on RTD: https://pywbem.readthedocs.io/en/stable_M.N/changes.html
 
-6.  Run the Safety tool:
+5.  Run the Safety tool:
 
     .. code-block:: sh
 
@@ -125,6 +117,13 @@ local clone of the ``pywbem/pywbem`` Git repo.
     If the safety run fails, you need to fix the safety issues that are
     reported.
 
+6.  Add a new tag for the version that is being released and push it to the
+    remote repo. This needs to be done before pushing the changes because the
+    version is calculated based on the most recent tag in the commit history.
+
+        git tag ${MNU}
+        git push --tags
+
 7.  Commit your changes and push the topic branch to the remote repo:
 
         git commit -asm "Release ${MNU}"
@@ -143,13 +142,10 @@ local clone of the ``pywbem/pywbem`` Git repo.
     have succeeded, merge the Pull Request (no review is needed). This
     automatically deletes the branch on GitHub.
 
-11. Add a new tag for the version that is being released and push it to
-    the remote repo. Clean up the local repo:
+11. Clean up the release branch on the local repo:
 
         git checkout ${BRANCH}
         git pull
-        git tag -f ${MNU}
-        git push -f --tags
         git branch -d release_${MNU}
 
 12. When releasing based on the master branch, create and push a new stable
@@ -275,23 +271,14 @@ local clone of the ``pywbem/pywbem`` Git repo.
         git pull
         git checkout -b start_${MNU}
 
-3.  Edit the version file:
-
-        vi pywbem/_version.py
-
-    and update the version to a draft version of the version that is being
-    started:
-
-        __version__ = 'M.N.U.dev1'
-
-4.  Edit the change log:
+3.  Edit the change log:
 
         vi docs/changes.rst
 
     and insert the following section before the top-most section:
 
-        pywbem M.N.U.dev1
-        -----------------
+        pywbem M.N.U.dev
+        ----------------
 
         This version contains all fixes up to version M.N-1.x.
 
@@ -313,6 +300,22 @@ local clone of the ``pywbem/pywbem`` Git repo.
 
         .. _`list of open issues`: https://github.com/pywbem/pywbem/issues
 
+4.  Add an initial Git tag for the new release stream and push it to the
+    remote repo.
+
+    Note: An initial tag is necessary because the automatic version calculation
+    done by setuptools-scm uses the most recent tag in the commit history and
+    increases the least significant part of the version by one, without
+    providing any controls to change that behavior. So without this initial tag
+    when developing 1.8.0, the most recent tag would be 1.7.0 and the calculated
+    version would be e.g. 1.7.1.dev11+g7c3eb911. The "a0" at the end of the tag
+    is necessary because it adds a new least significant part, so the rest of
+    the version is not increased. So when developing 1.8.0, the calculated
+    version is e.g. 1.8.0a1.dev11+g7c3eb911.
+
+        git tag ${MNU}a0
+        git push --tags
+
 5.  Commit your changes and push them to the remote repo:
 
         git commit -asm "Start ${MNU}"

MANIFEST.in

@@ -5,7 +5,7 @@ include README_PYPI.md
 include INSTALL.md
 include requirements.txt
 include test-requirements.txt
-include setup.py
+include pyproject.toml
 include build_moftab.py
 include mof_compiler
 include mof_compiler.bat