setuputils3 2.0.3__tar.gz → 2.2__tar.gz

{setuputils3-2.0.3 → setuputils3-2.2}/PKG-INFO

@@ -1,12 +1,11 @@
 Metadata-Version: 2.1
 Name: setuputils3
-Version: 2.0.3
+Version: 2.2
 Summary: A utility module to automate building setup configuration files.
 Home-page: http://pypi.org/project/setuputils3
 Author: Peter A. Donis
 Author-email: peterdonis@alum.mit.edu
 License: PSF
-Platform: UNKNOWN
 Classifier: Development Status :: 5 - Production/Stable
 Classifier: Environment :: Console
 Classifier: Intended Audience :: Developers
@@ -46,7 +45,10 @@ Using setuputils in this mode is simple: for each section of
 in the root of your source tree in files with an ``.in`` extension,
 one for each section that will end up in ``setup.cfg``. For example,
 you would put metadata in the file ``metadata.in``, options in the
-file ``options.in``, etc. You would not include anything that you want
+file ``options.in``, etc. For subsections, just use the subsection
+name as it would appear in ``setup.cfg`` as the base file name, so,
+for example, entry points would appear in ``options.entry_points.in``.
+Do not include anything in the ``.in`` files that you want
 ``setuputils`` to auto-discover, so, for example, if you want
 ``setuputils`` to auto-discover your packages, you would not include
 "packages" in your ``options.in`` file at all (whereas with
@@ -62,28 +64,50 @@ file for you. You can then look at it to make sure it is correct
 before using a build backend to build your distribution.
 
 With this mode, if you are using a PEP 517 compliant build backend, you
-do not need a ``setup.py`` script at all. (``Setuptools`` qualifies as
+do not need a ``setup.py`` script at all. You can use ``setuptools`` as
 such a backend as long as you include a ``pyproject.toml file`` and specify
-``setuptools`` in it, as described in the Python packaging documentation.)
+``setuptools`` in it, as described in the Python packaging documentation.
 If you do have a ``setup.py`` script, all it would need to contain is
 an import of ``setuptools`` and call to ``setuptools.setup()`` with no
 arguments (since all of the information needed is in ``setup.cfg``).
 
-Note, however, that if you have a ``setup.py`` script that was used with
-previous versions of ``setuputils``, you do not have to transition it to the
+You can also use ``setuputils`` itself as a PEP 517 compliant build
+backend. In this mode, you can still run ``setuputils`` as described above
+before doing your build to make sure ``setup.cfg`` is correct. But using
+``setuputils`` as your build backend ensures that ``setup.cfg`` will be
+rebuilt on every build to ensure consistency with the current state of
+your source tree. To use ``setuputils`` as your build backend, your
+``pyproject.toml`` should look like this:
+
+    [build-system]
+    requires = ["setuputils3 >= 2.1", "setuptools >= 40.8.0", "wheel"]
+    build-backend = "setuputils_build"
+
+You still need to include ``setuptools`` and ``wheel`` as build
+requirements, since ``setuputils`` depends on them; the ``setuputils``
+build backend is just a thin wrapper around ``setuptools.build_meta``
+that ensures that ``setup.cfg`` is built and up to date before the
+``setuptools`` build runs.
+
+Note that if you have a ``setup.py`` script that was used with previous
+versions of ``setuputils``, you do not have to transition it to the
 new format using ``.in`` files all at once. ``Setuputils`` will read any
 global variables that are defined in your ``setup.py``, as you would have
-done in previous ``setuputils versions``, and include them in what it
+done in previous ``setuputils`` versions, and include them in what it
 outputs to ``setup.cfg`` after processing them just as it would have in
 previous versions, so you can transition things incrementally if that works
 better for your project. (However, you should remove any calls to
 ``setup_vars`` in your ``setup.py`` script, leaving only the call to
 ``setuptools.setup()`` with no arguments, since all the information
-it needs will be in ``setup.cfg``.)
+it needs will be in ``setup.cfg``.) Note that if you have a ``setup.py``
+script, you cannot use ``setuputils`` as a build backend; you can only
+use it to generate ``setup.cfg`` before doing a build. Also note that if
+you are using ``setuputils`` in this "legacy" mode, you will have to
+include it in your source distributions (instead of just listing it as a
+requirement in ``pyprojects.toml``), since "legacy" mode builds have no
+way of specifying build requirements other than setuptools itself.
 
 See the module docstrings for more information.
 
 SETUPUTILS3 is Copyright (C) 2012-2022 by Peter A. Donis.
 Released under the Python Software Foundation License.
-
-

{setuputils3-2.0.3 → setuputils3-2.2}/README.md

@@ -25,7 +25,10 @@ Using setuputils in this mode is simple: for each section of
 in the root of your source tree in files with an ``.in`` extension,
 one for each section that will end up in ``setup.cfg``. For example,
 you would put metadata in the file ``metadata.in``, options in the
-file ``options.in``, etc. You would not include anything that you want
+file ``options.in``, etc. For subsections, just use the subsection
+name as it would appear in ``setup.cfg`` as the base file name, so,
+for example, entry points would appear in ``options.entry_points.in``.
+Do not include anything in the ``.in`` files that you want
 ``setuputils`` to auto-discover, so, for example, if you want
 ``setuputils`` to auto-discover your packages, you would not include
 "packages" in your ``options.in`` file at all (whereas with
@@ -41,24 +44,48 @@ file for you. You can then look at it to make sure it is correct
 before using a build backend to build your distribution.
 
 With this mode, if you are using a PEP 517 compliant build backend, you
-do not need a ``setup.py`` script at all. (``Setuptools`` qualifies as
+do not need a ``setup.py`` script at all. You can use ``setuptools`` as
 such a backend as long as you include a ``pyproject.toml file`` and specify
-``setuptools`` in it, as described in the Python packaging documentation.)
+``setuptools`` in it, as described in the Python packaging documentation.
 If you do have a ``setup.py`` script, all it would need to contain is
 an import of ``setuptools`` and call to ``setuptools.setup()`` with no
 arguments (since all of the information needed is in ``setup.cfg``).
 
-Note, however, that if you have a ``setup.py`` script that was used with
-previous versions of ``setuputils``, you do not have to transition it to the
+You can also use ``setuputils`` itself as a PEP 517 compliant build
+backend. In this mode, you can still run ``setuputils`` as described above
+before doing your build to make sure ``setup.cfg`` is correct. But using
+``setuputils`` as your build backend ensures that ``setup.cfg`` will be
+rebuilt on every build to ensure consistency with the current state of
+your source tree. To use ``setuputils`` as your build backend, your
+``pyproject.toml`` should look like this:
+
+    [build-system]
+    requires = ["setuputils3 >= 2.1", "setuptools >= 40.8.0", "wheel"]
+    build-backend = "setuputils_build"
+
+You still need to include ``setuptools`` and ``wheel`` as build
+requirements, since ``setuputils`` depends on them; the ``setuputils``
+build backend is just a thin wrapper around ``setuptools.build_meta``
+that ensures that ``setup.cfg`` is built and up to date before the
+``setuptools`` build runs.
+
+Note that if you have a ``setup.py`` script that was used with previous
+versions of ``setuputils``, you do not have to transition it to the
 new format using ``.in`` files all at once. ``Setuputils`` will read any
 global variables that are defined in your ``setup.py``, as you would have
-done in previous ``setuputils versions``, and include them in what it
+done in previous ``setuputils`` versions, and include them in what it
 outputs to ``setup.cfg`` after processing them just as it would have in
 previous versions, so you can transition things incrementally if that works
 better for your project. (However, you should remove any calls to
 ``setup_vars`` in your ``setup.py`` script, leaving only the call to
 ``setuptools.setup()`` with no arguments, since all the information
-it needs will be in ``setup.cfg``.)
+it needs will be in ``setup.cfg``.) Note that if you have a ``setup.py``
+script, you cannot use ``setuputils`` as a build backend; you can only
+use it to generate ``setup.cfg`` before doing a build. Also note that if
+you are using ``setuputils`` in this "legacy" mode, you will have to
+include it in your source distributions (instead of just listing it as a
+requirement in ``pyprojects.toml``), since "legacy" mode builds have no
+way of specifying build requirements other than setuptools itself.
 
 See the module docstrings for more information.
 

{setuputils3-2.0.3 → setuputils3-2.2}/pyproject.toml

@@ -1,3 +1,4 @@
 [build-system]
 requires = ["setuptools >= 40.8.0", "wheel"]
-build-backend = "setuptools.build_meta"
+build-backend = "setuputils_build"
+backend-path = ["."]

{setuputils3-2.0.3 → setuputils3-2.2}/setup.cfg

@@ -1,6 +1,6 @@
 [metadata]
 name = setuputils3
-version = 2.0.3
+version = 2.2
 description = A utility module to automate building setup configuration files.
 long_description = file: README.md
 long_description_content_type = text/markdown
@@ -23,6 +23,7 @@ classifiers =
 [options]
 py_modules = 
 	setuputils
+	setuputils_build
 
 [egg_info]
 egg_base = /tmp

{setuputils3-2.0.3 → setuputils3-2.2}/setuputils.py

@@ -22,49 +22,15 @@ have no way of getting an advance look at what the tool thinks should go
 into your distribution; you only see what's in the distribution after it
 is built.
 
-Using setuputils in this mode is simple: for each section of setup.cfg,
-you put options that you want to specify in advance rather than have
-setuputils auto-discover in an .in file in the root of your source tree.
-For example, you would put metadata in the file metadata.in, options in
-the file options.in, etc. You would not include anything that you want
-setuputils to auto-discover, so, for example, if you want setuputils to
-auto-discover your packages, you would not include "packages" in your
-options.in file at all (whereas with setuptools you would include
-"packages = find:" in your setup.cfg).
-
-(Note that, in addition to the standard setuptools keywords, there are
-a few extra keywords that are used by setuputils itself, either to allow
-simpler inputs that then get expanded into standard format, as with the
-"dev_status" keyword, or to allow you to pass options to setuputils to
-control its behavior, as with the "autodiscover" keyword. These keywords
-are described further in the appropriate function docstrings below.)
-
-Once you have created your .in files, then you simply execute
-
-    python3 -m setuputils
-
-in the root of your source tree. This will build the setup.cfg file for
-you. You can then look at it to make sure it is correct before using a
-build backend to build your distribution.
-
-With this mode, if you are using a PEP 517 compliant build backend, you
-do not need a setup.py script at all. (Setuptools qualifies as such a
-backend as long as you include a pyproject.toml file and specify
-setuptools in it, as described in the Python packaging documentation.)
-If you do have a setup.py script, all it would need to contain is
-an import of ``setuptools`` and call to ``setuptools.setup()`` with no
-arguments (since all of the information needed is in setup.cfg). Note,
-however, that if you have a setup.py script that was used with previous
-versions of setuputils, you do not have to transition it to the new
-format using .in files all at once. Setuputils will read any global
-variables that are defined in your setup.py, as you would have done in
-previous setuputils versions, and include them in what it outputs to
-setup.cfg after processing them just as it would have in previous
-versions, so you can transition things incrementally if that works
-better for your project. (However, you should remove any calls to
-setup_vars in your setup.py script, leaving only the call to
-``setuptools.setup()`` with no arguments, since all the information
-it needs will be in setup.cfg.)
+Using setuputils in this mode is described in the README file that comes
+with the setuputils distribution. This mode supports both being run as
+a stand-alone tool to build setup.cfg prior to doing an sdist or wheel
+build, and being run as a PEP 517 build backend that builds setup.cfg
+before each build to ensure consistency with the current state of your
+source tree. This mode also supports reading global variables from a
+setup.py script if that is present (see further comments below); but if
+setup.py is present, setuputils cannot be used as a build backend, it
+can only be used to generate setup.cfg prior to doing a build.
 
 (Note that extension modules are currently not supported in setup.cfg,
 so you cannot use setuputils in setup.cfg mode if your distribution
@@ -998,7 +964,7 @@ def strtobool(value):
 
 
 def read_in_lines(lines,
-                  sep="=", listsep=",", comparison_ops=("==", ">", "<")):
+                  sep=" = ", endsep=" =", listsep=","):
     
     in_vars = {}
     open_key = None
@@ -1015,9 +981,9 @@ def read_in_lines(lines,
         line = line.strip()
         if not line:
             continue
-        if (not dangling) and (sep in line) and all(s not in line for s in comparison_ops):
+        if (not dangling) and ((sep in line) or line.endswith(endsep)):
             close_open_key()
-            key, value = (s.strip() for s in line.split(sep))
+            key, value = (s.strip() for s in line.split(endsep if line.endswith(endsep) else sep))
             if value:
                 key_type = supported_keywords.get(key, type(value))
                 if key_type in (list, dict):
@@ -1043,10 +1009,14 @@ def read_in_lines(lines,
     return in_vars
 
 
+def in_filename(section):
+    return "{}.in".format(section)
+
+
 def read_in_files():
     varmap = {}
     for section, _ in setup_cfg_sections:
-        filename = "{}.in".format(section)
+        filename = in_filename(section)
         if os.path.isfile(filename):
             with open(filename, 'r') as f:
                 lines = f.readlines()

setuputils3-2.2/setuputils_build.py

@@ -0,0 +1,40 @@
+#!/usr/bin/env python3
+"""
+Module SETUPUTILS_BUILD -- PEP 517 backend for setuputils
+Copyright (C) 2012-2022 by Peter A. Donis
+
+Released under the Python Software Foundation License.
+"""
+
+import os
+
+
+class Builder(object):
+    
+    setuptools_fns = (
+        'get_requires_for_build_wheel',
+        'get_requires_for_build_sdist',
+        'prepare_metadata_for_build_wheel',
+        'build_sdist',
+        'build_wheel',
+    )
+    
+    def __init__(self):
+        self.ensure_setup_cfg()
+        import setuptools.build_meta
+        for fname in self.setuptools_fns:
+            setattr(self, fname, getattr(setuptools.build_meta, fname))
+    
+    def ensure_setup_cfg(self):
+        import setuputils
+        if any(os.path.isfile(setuputils.in_filename(section)) for section, _ in setuputils.setup_cfg_sections):
+            setuputils.write_setup_cfg()
+
+
+_builder = Builder()
+
+get_requires_for_build_wheel = _builder.get_requires_for_build_wheel
+get_requires_for_build_sdist = _builder.get_requires_for_build_sdist
+prepare_metadata_for_build_wheel = _builder.prepare_metadata_for_build_wheel
+build_wheel = _builder.build_wheel
+build_sdist = _builder.build_sdist