Metadata-Version: 2.4
Name: plone.meta
Version: 2.2.0
Summary: Applies a standard set of configuration files for Plone repositories
Author-email: Plone Foundation <releaseteam@plone.org>, Gil Forcada Codinachs <gil.gnome@gmail.com>
License:                     GNU GENERAL PUBLIC LICENSE
                               Version 2, June 1991
        
         Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
         51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
         Everyone is permitted to copy and distribute verbatim copies
         of this license document, but changing it is not allowed.
        
                                    Preamble
        
          The licenses for most software are designed to take away your
        freedom to share and change it.  By contrast, the GNU General Public
        License is intended to guarantee your freedom to share and change free
        software--to make sure the software is free for all its users.  This
        General Public License applies to most of the Free Software
        Foundation's software and to any other program whose authors commit to
        using it.  (Some other Free Software Foundation software is covered by
        the GNU Lesser General Public License instead.)  You can apply it to
        your programs, too.
        
          When we speak of free software, we are referring to freedom, not
        price.  Our General Public Licenses are designed to make sure that you
        have the freedom to distribute copies of free software (and charge for
        this service if you wish), that you receive source code or can get it
        if you want it, that you can change the software or use pieces of it
        in new free programs; and that you know you can do these things.
        
          To protect your rights, we need to make restrictions that forbid
        anyone to deny you these rights or to ask you to surrender the rights.
        These restrictions translate to certain responsibilities for you if you
        distribute copies of the software, or if you modify it.
        
          For example, if you distribute copies of such a program, whether
        gratis or for a fee, you must give the recipients all the rights that
        you have.  You must make sure that they, too, receive or can get the
        source code.  And you must show them these terms so they know their
        rights.
        
          We protect your rights with two steps: (1) copyright the software, and
        (2) offer you this license which gives you legal permission to copy,
        distribute and/or modify the software.
        
          Also, for each author's protection and ours, we want to make certain
        that everyone understands that there is no warranty for this free
        software.  If the software is modified by someone else and passed on, we
        want its recipients to know that what they have is not the original, so
        that any problems introduced by others will not reflect on the original
        authors' reputations.
        
          Finally, any free program is threatened constantly by software
        patents.  We wish to avoid the danger that redistributors of a free
        program will individually obtain patent licenses, in effect making the
        program proprietary.  To prevent this, we have made it clear that any
        patent must be licensed for everyone's free use or not licensed at all.
        
          The precise terms and conditions for copying, distribution and
        modification follow.
        
                            GNU GENERAL PUBLIC LICENSE
           TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
        
          0. This License applies to any program or other work which contains
        a notice placed by the copyright holder saying it may be distributed
        under the terms of this General Public License.  The "Program", below,
        refers to any such program or work, and a "work based on the Program"
        means either the Program or any derivative work under copyright law:
        that is to say, a work containing the Program or a portion of it,
        either verbatim or with modifications and/or translated into another
        language.  (Hereinafter, translation is included without limitation in
        the term "modification".)  Each licensee is addressed as "you".
        
        Activities other than copying, distribution and modification are not
        covered by this License; they are outside its scope.  The act of
        running the Program is not restricted, and the output from the Program
        is covered only if its contents constitute a work based on the
        Program (independent of having been made by running the Program).
        Whether that is true depends on what the Program does.
        
          1. You may copy and distribute verbatim copies of the Program's
        source code as you receive it, in any medium, provided that you
        conspicuously and appropriately publish on each copy an appropriate
        copyright notice and disclaimer of warranty; keep intact all the
        notices that refer to this License and to the absence of any warranty;
        and give any other recipients of the Program a copy of this License
        along with the Program.
        
        You may charge a fee for the physical act of transferring a copy, and
        you may at your option offer warranty protection in exchange for a fee.
        
          2. You may modify your copy or copies of the Program or any portion
        of it, thus forming a work based on the Program, and copy and
        distribute such modifications or work under the terms of Section 1
        above, provided that you also meet all of these conditions:
        
            a) You must cause the modified files to carry prominent notices
            stating that you changed the files and the date of any change.
        
            b) You must cause any work that you distribute or publish, that in
            whole or in part contains or is derived from the Program or any
            part thereof, to be licensed as a whole at no charge to all third
            parties under the terms of this License.
        
            c) If the modified program normally reads commands interactively
            when run, you must cause it, when started running for such
            interactive use in the most ordinary way, to print or display an
            announcement including an appropriate copyright notice and a
            notice that there is no warranty (or else, saying that you provide
            a warranty) and that users may redistribute the program under
            these conditions, and telling the user how to view a copy of this
            License.  (Exception: if the Program itself is interactive but
            does not normally print such an announcement, your work based on
            the Program is not required to print an announcement.)
        
        These requirements apply to the modified work as a whole.  If
        identifiable sections of that work are not derived from the Program,
        and can be reasonably considered independent and separate works in
        themselves, then this License, and its terms, do not apply to those
        sections when you distribute them as separate works.  But when you
        distribute the same sections as part of a whole which is a work based
        on the Program, the distribution of the whole must be on the terms of
        this License, whose permissions for other licensees extend to the
        entire whole, and thus to each and every part regardless of who wrote it.
        
        Thus, it is not the intent of this section to claim rights or contest
        your rights to work written entirely by you; rather, the intent is to
        exercise the right to control the distribution of derivative or
        collective works based on the Program.
        
        In addition, mere aggregation of another work not based on the Program
        with the Program (or with a work based on the Program) on a volume of
        a storage or distribution medium does not bring the other work under
        the scope of this License.
        
          3. You may copy and distribute the Program (or a work based on it,
        under Section 2) in object code or executable form under the terms of
        Sections 1 and 2 above provided that you also do one of the following:
        
            a) Accompany it with the complete corresponding machine-readable
            source code, which must be distributed under the terms of Sections
            1 and 2 above on a medium customarily used for software interchange; or,
        
            b) Accompany it with a written offer, valid for at least three
            years, to give any third party, for a charge no more than your
            cost of physically performing source distribution, a complete
            machine-readable copy of the corresponding source code, to be
            distributed under the terms of Sections 1 and 2 above on a medium
            customarily used for software interchange; or,
        
            c) Accompany it with the information you received as to the offer
            to distribute corresponding source code.  (This alternative is
            allowed only for noncommercial distribution and only if you
            received the program in object code or executable form with such
            an offer, in accord with Subsection b above.)
        
        The source code for a work means the preferred form of the work for
        making modifications to it.  For an executable work, complete source
        code means all the source code for all modules it contains, plus any
        associated interface definition files, plus the scripts used to
        control compilation and installation of the executable.  However, as a
        special exception, the source code distributed need not include
        anything that is normally distributed (in either source or binary
        form) with the major components (compiler, kernel, and so on) of the
        operating system on which the executable runs, unless that component
        itself accompanies the executable.
        
        If distribution of executable or object code is made by offering
        access to copy from a designated place, then offering equivalent
        access to copy the source code from the same place counts as
        distribution of the source code, even though third parties are not
        compelled to copy the source along with the object code.
        
          4. You may not copy, modify, sublicense, or distribute the Program
        except as expressly provided under this License.  Any attempt
        otherwise to copy, modify, sublicense or distribute the Program is
        void, and will automatically terminate your rights under this License.
        However, parties who have received copies, or rights, from you under
        this License will not have their licenses terminated so long as such
        parties remain in full compliance.
        
          5. You are not required to accept this License, since you have not
        signed it.  However, nothing else grants you permission to modify or
        distribute the Program or its derivative works.  These actions are
        prohibited by law if you do not accept this License.  Therefore, by
        modifying or distributing the Program (or any work based on the
        Program), you indicate your acceptance of this License to do so, and
        all its terms and conditions for copying, distributing or modifying
        the Program or works based on it.
        
          6. Each time you redistribute the Program (or any work based on the
        Program), the recipient automatically receives a license from the
        original licensor to copy, distribute or modify the Program subject to
        these terms and conditions.  You may not impose any further
        restrictions on the recipients' exercise of the rights granted herein.
        You are not responsible for enforcing compliance by third parties to
        this License.
        
          7. If, as a consequence of a court judgment or allegation of patent
        infringement or for any other reason (not limited to patent issues),
        conditions are imposed on you (whether by court order, agreement or
        otherwise) that contradict the conditions of this License, they do not
        excuse you from the conditions of this License.  If you cannot
        distribute so as to satisfy simultaneously your obligations under this
        License and any other pertinent obligations, then as a consequence you
        may not distribute the Program at all.  For example, if a patent
        license would not permit royalty-free redistribution of the Program by
        all those who receive copies directly or indirectly through you, then
        the only way you could satisfy both it and this License would be to
        refrain entirely from distribution of the Program.
        
        If any portion of this section is held invalid or unenforceable under
        any particular circumstance, the balance of the section is intended to
        apply and the section as a whole is intended to apply in other
        circumstances.
        
        It is not the purpose of this section to induce you to infringe any
        patents or other property right claims or to contest validity of any
        such claims; this section has the sole purpose of protecting the
        integrity of the free software distribution system, which is
        implemented by public license practices.  Many people have made
        generous contributions to the wide range of software distributed
        through that system in reliance on consistent application of that
        system; it is up to the author/donor to decide if he or she is willing
        to distribute software through any other system and a licensee cannot
        impose that choice.
        
        This section is intended to make thoroughly clear what is believed to
        be a consequence of the rest of this License.
        
          8. If the distribution and/or use of the Program is restricted in
        certain countries either by patents or by copyrighted interfaces, the
        original copyright holder who places the Program under this License
        may add an explicit geographical distribution limitation excluding
        those countries, so that distribution is permitted only in or among
        countries not thus excluded.  In such case, this License incorporates
        the limitation as if written in the body of this License.
        
          9. The Free Software Foundation may publish revised and/or new versions
        of the General Public License from time to time.  Such new versions will
        be similar in spirit to the present version, but may differ in detail to
        address new problems or concerns.
        
        Each version is given a distinguishing version number.  If the Program
        specifies a version number of this License which applies to it and "any
        later version", you have the option of following the terms and conditions
        either of that version or of any later version published by the Free
        Software Foundation.  If the Program does not specify a version number of
        this License, you may choose any version ever published by the Free Software
        Foundation.
        
          10. If you wish to incorporate parts of the Program into other free
        programs whose distribution conditions are different, write to the author
        to ask for permission.  For software which is copyrighted by the Free
        Software Foundation, write to the Free Software Foundation; we sometimes
        make exceptions for this.  Our decision will be guided by the two goals
        of preserving the free status of all derivatives of our free software and
        of promoting the sharing and reuse of software generally.
        
                                    NO WARRANTY
        
          11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
        FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
        OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
        PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
        OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
        MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
        TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
        PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
        REPAIR OR CORRECTION.
        
          12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
        WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
        REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
        INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
        OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
        TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
        YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
        PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
        POSSIBILITY OF SUCH DAMAGES.
        
                             END OF TERMS AND CONDITIONS
        
                    How to Apply These Terms to Your New Programs
        
          If you develop a new program, and you want it to be of the greatest
        possible use to the public, the best way to achieve this is to make it
        free software which everyone can redistribute and change under these terms.
        
          To do so, attach the following notices to the program.  It is safest
        to attach them to the start of each source file to most effectively
        convey the exclusion of warranty; and each file should have at least
        the "copyright" line and a pointer to where the full notice is found.
        
            <one line to give the program's name and a brief idea of what it does.>
            Copyright (C) <year>  <name of author>
        
            This program is free software; you can redistribute it and/or modify
            it under the terms of the GNU General Public License as published by
            the Free Software Foundation; either version 2 of the License, or
            (at your option) any later version.
        
            This program is distributed in the hope that it will be useful,
            but WITHOUT ANY WARRANTY; without even the implied warranty of
            MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
            GNU General Public License for more details.
        
            You should have received a copy of the GNU General Public License along
            with this program; if not, write to the Free Software Foundation, Inc.,
            51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
        
        Also add information on how to contact you by electronic and paper mail.
        
        If the program is interactive, make it output a short notice like this
        when it starts in an interactive mode:
        
            Gnomovision version 69, Copyright (C) year name of author
            Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
            This is free software, and you are welcome to redistribute it
            under certain conditions; type `show c' for details.
        
        The hypothetical commands `show w' and `show c' should show the appropriate
        parts of the General Public License.  Of course, the commands you use may
        be called something other than `show w' and `show c'; they could even be
        mouse-clicks or menu items--whatever suits your program.
        
        You should also get your employer (if you work as a programmer) or your
        school, if any, to sign a "copyright disclaimer" for the program, if
        necessary.  Here is a sample; alter the names:
        
          Yoyodyne, Inc., hereby disclaims all copyright interest in the program
          `Gnomovision' (which makes passes at compilers) written by James Hacker.
        
          <signature of Ty Coon>, 1 April 1989
          Ty Coon, President of Vice
        
        This General Public License does not permit incorporating your program into
        proprietary programs.  If your program is a subroutine library, you may
        consider it more useful to permit linking proprietary applications with the
        library.  If this is what you want to do, use the GNU Lesser General
        Public License instead of this License.
        
Project-URL: Homepage, https://github.com/plone/meta
Project-URL: Issue Tracker, https://github.com/plone/meta/issues
Project-URL: Changelog, https://github.com/plone/meta/blob/main/CHANGES.md
Project-URL: Documentation, https://6.docs.plone.org/developer-guide/standardize-python-project-configuration.html
Keywords: plone,packaging
Classifier: Development Status :: 3 - Alpha
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: GNU General Public License v2 (GPLv2)
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Programming Language :: Python :: Implementation :: CPython
Classifier: Natural Language :: English
Classifier: Operating System :: OS Independent
Requires-Python: >=3.9
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: setuptools
Requires-Dist: Jinja2
Requires-Dist: editorconfig
Requires-Dist: pyyaml
Requires-Dist: tomlkit
Requires-Dist: tox
Requires-Dist: validate-pyproject[all]
Requires-Dist: zest.releaser
Dynamic: license-file

# plone.meta

`plone.meta` defines and standardizes a common set of configuration files across Plone related Python repositories.
It does not cover the following.

-   Volto or any other JavaScript-based project, which has its own ecosystem.
-   Monorepo projects with backend and frontend code bases, such as those created by [Cookieplone](https://github.com/plone/cookieplone).
    Repositories must have a single Python package at the top level.
-   Projects that support multiple versions of Plone in the same branch.


## Setup

Create a Python virtual environment and install `plone.meta` via pip.

```shell
python3 -m venv venv
venv/bin/pip install plone.meta
```


## `config-package` usage

The command `config-package` from `plone.meta` creates or overwrites configuration files for your project.
See a current list of [configuration files](#config-package-configuration-files) that it will create or overwrite.

This command has several [command line options](#config-package-command-line-options) that you can use to override the default options.

When you run this command, it automatically goes through the following steps.

1.  It creates a new git branch from the current branch in your project.
1.  If the file {file}`.meta.toml` is not present in the project, then it creates this and the other new configuration files from `plone.meta`'s Jinja2 templates.
    Otherwise, it reads the file {file}`.meta.toml` for regenerating the configuration files.
1.  It writes the configuration files.
1.  It creates a change log entry.
1.  By default, it commits changes.
1.  It optionally adds packages, pushes commits, or runs tox from the configuration files.

> [!TIP]
> If you prefer to name the new git branch instead of letting the command name it using its default naming scheme, then either create a new branch `my-new-branch`, switch to it, and use the `--branch current` option, or do all that in one step with the `--branch my-new-branch` option.

> [!TIP]
> If you prefer to review changes before committing them, then use the `--no-commit` option.

For help for `config-package`, use the following command.

```shell
venv/bin/config-package --help
```

You can request more extension points if `plone.meta` does not fulfill your needs in the [issue tracker](https://github.com/plone/meta/issues/new).


### Generate configuration files

Now you can run the command `config-package` to generate configuration files from Jinja2 template files to manage your project.

```shell
venv/bin/config-package [OPTIONS] PATH/TO/PACKAGE
```


### Manage configuration files

For each of the configuration files, you should edit its [corresponding stanza](#config-package-configuration-files) in the file `.meta.toml` to customize them.

> [!WARNING]
> Do not directly edit the configuration files that `plone.meta` manages.
Anytime someone runs the command `config-package`, any changes made in these files will get clobbered.

Commit your changes, then run the command `config-package` to regenerate configuration files from your project's `.meta.toml`.

```shell
venv/bin/config-package [OPTIONS] PATH/TO/PACKAGE
```


### `config-package` command line options

`config-package` supports the following command line options.

-   `--branch BRANCH_NAME`: Define a specific git branch name to create for the changes.
    By default, the script creates one, which includes the name of the configuration type.
    > [!TIP]
    > Use `current` to update the current branch.
-   `--commit-msg MSG`: Use `MSG` as the commit message instead of the default one.
-   `--no-commit`: Don't automatically commit changes after the configuration run.
-   `-h, --help`: Display help.
-   `--push`: Push changes at the end of the configuration run.
    By default, the changes are _not_ pushed.
-   `--tox`: Whether to run `tox` on the repository.
    By default, it does not run.
-   `--track`: Whether the package being configured should be added to `defaults/packages.txt`.
    By default, they are _not_ added.
-   `-t, --type`: define the configuration type.
    At this time, `default` is the only option.
    This option is only needed one time as their values are stored in `.meta.toml`.


### `config-package` configuration files

`plone.meta` generates configuration files in your local repository.
Currently, the files that `plone.meta` manages are the following.

-   `.meta.toml`: `plone.meta`'s configuration file
-   `.editorconfig`: configuration meant to be read by code editors
-   `.flake8`: [`flake8`](https://pypi.org/project/flake8) configuration
-   `.gitignore`: list of file/folders patterns that `git` should ignore
-   `.github/workflows/meta.yml`: GitHub workflows to run the testing and code quality and analysis tools on GitHub, provided the repository is hosted at github.com
-   `.gitlab-ci.yml`: GitLab CI configuration, provided the repository is hosted at gitlab.com
-   `.pre-commit-config.yaml`: [`pre-commit`](https://pypi.org/project/pre-commit) configuration
-   `pyproject.toml`: configuration options for a wide variety of Python tooling
-   `tox.ini`: [`tox`](https://pypi.org/project/tox) configuration, _the most important file_

You can find the _template_ files for each of these files in the `config/default` folder of this `plone.meta` repository.

You will notice that they have a `.jinja` extension.
That's because the files are not merely copied over to the target repository, but rather they are enhanced and adapted on the way to their destination.

The following sections describe how to configure each of the configuration files.


#### `.editorconfig`

Add the `[editorconfig]` TOML table in `.meta.toml`, and set extra configuration for `editorconfig` under the `extra_lines` key.

```toml
[editorconfig]
extra_lines = """
_your own configuration lines_
"""
```

If you want to set the indentation to four spaces for frontend related files, add the following to your `.meta.toml`.

```toml
[editorconfig]
extra_lines = """
[*.{json,jsonl,js,jsx,ts,tsx,css,less,scss}]
indent_size = 4
"""
```


#### `.flake8`

Add the `[flake8]` TOML table in `.meta.toml`, and set the extra configuration for `flake8` under the `extra_lines` key.

```toml
[flake8]
extra_lines = """
_your own configuration lines_
"""
```


#### `.gitignore`

Add the `[gitignore]` TOML table in `.meta.toml`, and set the extra configuration for `git` under the `extra_lines` key.

```toml
[gitignore]
extra_lines = """
_your own configuration lines_
"""
```


#### `.github/workflows/test-matrix.yml`

Run the distribution test on a combination of Plone and Python versions.

> [!NOTE]
> See the `test_matrix` option in [`tox`](#toxini) configuration file.

> [!TIP]
> 🍀 `plone.meta` tries to be a bit more environmentally friendly.
> On GitHub, only the first and last Python versions will be added for testing.


#### `.github/workflows/meta.yml`

Customize the GitHub Action jobs run on every change pushed to GitHub.

Add the `[github]` TOML table in `.meta.toml`, and set the enabled jobs with the `jobs` key.

```toml
[github]
jobs = [
    "qa",
    "coverage",
    "dependencies",
    "release_ready",
    "circular",
    ]
```

It is possible to configure from which branch or tag of `plone.meta` to get the workflow files by setting the value of the `ref` key.
In the following example, all GitHub workflows would come from the `v3` tag, instead of the default `main` branch.

```toml
[github]
ref = "v3"
```

To set environment variables for all jobs, specify the `env` key as follows.

```toml
[github]
env = """
  debug: 1
  image-name: 'org/image'
  image-tag: 'latest'
"""
```

To install specific operating system level dependencies, which must be Ubuntu package names, specify the following key.

```toml
[github]
os_dependencies = "git libxml2"
```

Extend GitHub workflow configuration with additional jobs by setting the values for the `extra_lines` key.

```toml
[github]
extra_lines = """
  another:
    uses: org/repo/.github/workflows/file.yml@main
"""
```


#### `.gitlab-ci.yml`

Add the `[gitlab]` TOML table in `.meta.toml`, and set the extra configuration for GitLab CI under the `extra_lines` key.

```toml
[gitlab]
extra_lines = """
_your own configuration lines_
"""
```

Specify custom Docker images in the `custom_images` key.

The dictionary keys needs to be Python versions and the value a Docker image for that Python version.

```toml
[gitlab]
custom_images = {"3.13" = "python:3.13-bookworm", "3.12" = "python:3.12-bookworm"}
```

> [!TIP]
> To tweak the jobs that will be run, you can customize the `test_matrix` option from `[tox]` table.

To install specific test and coverage dependencies, add the `os_dependencies` key as follows.

```toml
[gitlab]
os_dependencies = """
    - apt-get install libxslt libxml2
"""
```

You can customize the enabled GitLab jobs with the `jobs` key.

```toml
[gitlab]
jobs = [
  "lint",
  "release-ready",
  "dependencies",
  "circular-dependencies",
  "testing",
  "coverage",
]
```


#### `.pre-commit-config.yaml`

Add the `[pre_commit]` TOML table in `.meta.toml`, and set the extra configuration for `pre-commit` under the `extra_lines` key.

```toml
[pre_commit]
extra_lines = """
_your own configuration lines_
"""
```

Extend [`zpretty`](https://pypi.org/project/zpretty) configuration by setting the values for the `zpretty_extra_lines` key.

```toml
[pre_commit]
zpretty_extra_lines = """
_your own configuration lines_
"""
```

Extend [codespell](https://pypi.org/project/codespell) configuration by setting the values for the `codespell_extra_lines` key.

```toml
[pre_commit]
codespell_extra_lines = """
_your own configuration lines_
"""
```

Extend [Flake8](https://pypi.org/project/flake8) configuration by setting the values for the `flake8_extra_lines` key.
For example, to add extra Flake8 plugins, you would specify `additional_dependencies` as shown.

```toml
[pre_commit]
flake8_extra_lines = """
        additional_dependencies:
          - flake8-debugger
          - flake8-deprecated
"""
```

Extend [i18ndude](https://pypi.org/project/i18ndude) configuration by setting the values for the `i18ndude_extra_lines` key.
For example, to add extra i18ndude plugins, you would specify `additional_dependencies` as shown.

```toml
[pre_commit]
i18ndude_extra_lines = """
        additional_dependencies:
          - toml
"""
```

If you want to disable the i18ndude check, add the following pre-commit configuration option to your `.meta.toml` file.

```toml
[pre_commit]
i18ndude_extra_lines = """
        pass_filenames: false
"""
```


#### `pyproject.toml`

Add the `[pyproject]` TOML table in `.meta.toml`, and set configuration for any extra tool that you use for the `extra_lines` key.

```toml
[pyproject]
extra_lines = """
_your own configuration lines_
"""
```

Extend [codespell](https://pypi.org/project/codespell) configuration by setting the values for the `codespell_ignores` and `codespell_skip` keys.

```toml
[pyproject]
codespell_ignores = "foo,bar"
codespell_skip = "*.po,*.map,package-lock.json"
```

Extend [z3c.dependencychecker](https://pypi.org/project/z3c.dependencychecker) configuration by setting the values for the `dependencies_ignores` and `dependencies_mappings` keys.

```toml
[pyproject]
dependencies_ignores = "['zestreleaser.towncrier']"
dependencies_mappings = [
  "gitpython = ['git']",
  "pygithub = ['github']",
]
```

Extend [check-manifest](https://pypi.org/project/check-manifest) configuration by setting the values for the `check_manifest_ignores` key.

```toml
[pyproject]
check_manifest_ignores = """
    "*.map.js",
    "*.pyc",
"""
```

Extend [Black](https://pypi.org/project/black) configuration by setting the values for the `black_extra_lines` key.

```toml
[pyproject]
black_extra_lines = """
_custom configuration_
"""
```

Extend [isort](https://pypi.org/project/isort) configuration by setting the values for the `isort_extra_lines` key.

```toml
[pyproject]
isort_extra_lines = """
_custom configuration_
"""
```


##### `towncrier` configuration

If your project contains a `news/` folder, `plone.meta` will add the configuration for `towncrier`.

If your `CHANGES` file has the extension `.md`, a `changelog_template.jinja` template will be generated inside the `news/` folder.

Configure [`towncrier`](https://pypi.org/project/towncrier) [`issue_format`](https://towncrier.readthedocs.io/en/stable/configuration.html) by setting the new format in the `towncrier_issue_format` key.

```toml
[pyproject]
towncrier_issue_format = "[#{issue}](https://github.com/plonegovbr/plonegovbr.portal/issues/{issue})"
```

Extend [`towncrier`](https://pypi.org/project/towncrier) configuration by setting the values for the `towncrier_extra_lines` key.

```toml
[pyproject]
towncrier_extra_lines = """
_custom configuration_
"""
```


#### `tox.ini`

Depending on the test runner that you want to use, `plone.meta` will adapt `tox.ini` to it.

In the `[tox]` TOML table in `.meta.toml`, set the value for the key `test_runner` to `pytest` if you want to use [`pytest`](https://pypi.org/project/pytest).
By default, it falls back to use [zope.testrunner](https://pypi.org/project/zope.testrunner).

Likewise, the root path where the tests are to be found can be specified under the key `test_path`.
By default, it is set to nothing, that is, the repository's top level is already importable and thus the tests can be found directly.

If either a `tests` or `src` folder exists, then they are used as safe fallbacks.

Add the `[tox]` TOML table in `.meta.toml`, and set the extra configuration for `tox` under the `extra_lines` key.

```toml
[tox]
extra_lines = """
_your own configuration lines_
"""
```

`plone.meta` generates a list of Python and Plone version combinations to run the distribution tests.

You can customize that by defining your testing matrix:

```toml
[tox]
test_matrix = { "6.1" = ["3.13", "3.10"], "6.0" = ["*"] }
```

When the list of Python versions is `*`, `plone.meta` replaces it with the default Python version list for this Plone version.

Extend the list of default `tox` environments in the `envlist_lines` key.
Add extra top level configuration for `tox` in the `config_lines` key.

```toml
[tox]
envlist_lines = """
    my_other_environment
"""
config_lines = """
my_extra_top_level_tox_configuration_lines
"""
```

Customize the default values for all `tox` environments in the `testenv_options` key.

```toml
[tox]
testenv_options = """
basepython = /usr/bin/python3.8
"""
```

Extend the list of `extras` that need to be installed for running the test suite and generate the coverage report by setting them on the `test_extras` key.

```toml
[tox]
test_extras = """
    tests
    widgets
"""
```

If your package uses [mxdev](https://pypi.org/project/mxdev/) to handle source checkouts for dependencies, you can set the `use_mxdev` key to ensure `tox` will first run mxdev.
You also need to manually set the installation of additional packages that `mxdev` pulls in with the `test_deps_additional` key.

```toml
[tox]
use_mxdev = true
test_deps_additional = """
    -esources/plonegovbr.portal_base[test]
"""
```

When using `plone.meta` outside of plone core packages, there might be extra version pins, or overrides over the official versions.
To specify a custom constraints file, use the `constraints_files` key.

Generating a custom `constraints.txt` is out of scope for `plone.meta` itself.
There are plenty of tools that can do that though.

> [!WARNING]
> You need to specify the same Plone versions as in the `test_matrix` option or the default provided by `plone.meta`.

```toml
[tox]
constraints_files = { "6.1" = "https://my-server.com/constraints-6.1.txt", "6.0" = "https://my-server.com/constraints-6.0.txt" }
```

Extend the list of custom environment variables that the test and coverage environments can get in the `test_environment_variables` key.

```toml
[tox]
test_environment_variables = """
    PIP_EXTRA_INDEX_URL=https://my-pypi.my-server.com/
"""
```

For packages that have `plone.app.robotframework` based tests, it automatically detects it and primes [Playwright](https://playwright.dev/) to install the needed browsers.


### Manage multiple repositories with `multi-call`

The `config-package` command runs only on a single repository.
To update multiple repositories at once, you can use the command `multi-call`.
It runs on all repositories listed in a `packages.txt` file.

To run `multi-call` on all packages listed in a `packages.txt` file use the following command with positional arguments as shown.

-   The file path the Python script to be called.
-   The file path to `packages.txt`, which lists repositories of packages on which the Python script will be called.
-   The file path to the directory where the clones of the repositories are stored.
-   Arguments to pass into the Python script.

```shell
bin/multi-call <name-of-the-script.py> <path-to-packages.txt> <path-to-clones> <arguments-for-script>
```

The script performs the following steps for each line in the given `packages.txt` that does not start with a hash mark (`#`).

1.  Check if there is a repository in `<path-to-clones>` with the name of the repository.
    If it does not exist, then clone it.
    If it exists, then clean the clone from changes, switch to the `master` branch, and pull from the origin.
2.  Call the given script with the package name and arguments for the script.

> [!CAUTION]
> Running this script stashes any uncommitted changes in the repositories.
> Run `git stash pop` to recover them.


### Re-enable GitHub Actions with `re-enable-actions`

After a certain period of time without commits to a repository, GitHub automatically disables Actions.
You can re-enable them manually per repository.
`re-enable-actions` can do this for all repositories.
It does no harm if Actions are already enabled for a repository.


#### Setup GitHub CLI

-   Install [GitHub's CLI application](https://github.com/cli/cli).
-   Authorize using the application:
    -   `gh auth login`
    -   It is probably enough to do it once.


#### `re-enable-actions` usage

Use the following command.

```shell
venv/bin/re-enable-actions
```


## Explanation

This section provides explanation of design decisions and capabilities of `plone.meta`.


### Project management

By using `plone.meta`, you can have the same developer experience (DX)
across all Plone related packages.

The idea is to make it mandatory for repositories under the [GitHub Plone organization](https://github.com/plone),
while encouraging its adoption for the repositories under the [collective Plone organization](https://github.com/collective)
and even your own private packages for your customers.

With this configuration in place,
any developer has the answer to the following questions at their fingertips:

-   Do the tests of this package pass?
-   What's the coverage of the test suite?
-   Is the package ready to be released?
-   Are all dependencies clearly defined?
-   What does the dependency graph look like?
-   Are there any circular dependency problems?
-   Is the code formatted to some agreed upon standards?
-   Do all agreed upon code quality checks pass?

To find the answers to these questions, you can run the following commands.

```shell
# run the test suite
tox -e test
# get a coverage report
tox -e coverage
# check if the package is ready to be released
tox -e release-check
# check if the dependencies are all specified
tox -e dependencies
# generate a dependency graph
tox -e dependencies-graph
# check if there are circular dependencies
tox -e circular
# format the code
tox -e format
# run all sorts of QA tools (code smells, typo finder...)
tox -e lint
```

As seen above, [`tox`](https://pypi.org/project/tox) provides the answers.

Tooling is like fashion, it keeps evolving and changing.

The great power behind `plone.meta` is that when we implement a better solution or tool,
we can swiftly move all packages to the new approach, making it as painless as possible!


### Configuration philosophy

It is one thing to standardize, yet another to be flexible enough to adapt to each repository's particular needs.

Fortunately `plone.meta` tries its best to accomplish both:

- it provides sane defaults
- it allows extension of the defaults with custom configuration

The configuration files have comments all over them
with instructions on how to extend, modify, and influence
what `plone.meta` ends up adding on those files.

Those options are to be stored,
as it is mentioned on the comments themselves,
in `.meta.toml`.

This way, when the configuration files get regenerated,
`plone.meta` reads the configuration in `.meta.toml`
and reapplies the specific configuration on the other files.

See the specific configuration files sections below on how to extend and modify each configuration file.

The idea behind the configuration system
in `plone.meta` controlled configuration files is to make it as simple as possible.

Rather than adding plenty of configuration options,
almost all configuration files have an `extra_lines` section
that allows you to paste as much configuration as you want there.

In this way, it provides a simple, yet powerful, extension mechanism.

There are a few, and growing, other configuration options in a few files,
where the simple approach described above is not enough.

## GitHub Actions shared automations

To [avoid duplicating workflow content](https://docs.github.com/en/actions/sharing-automations/avoiding-duplication) across Plone projects, the [`plone/meta` repository](https://github.com/plone/meta) provides a set of reusable workflows and composite actions.

These actions and workflows are used by code bases generated with [`Cookieplone`](https://github.com/plone/cookieplone) and [`cookieplone-templates`](https://github.com/plone/cookieplone-templates).

## Composite actions

Composite actions combine commonly used steps into reusable units that simplify writing GitHub workflows.

### `setup_backend_uv`

The action `setup_backend_uv` sets up and installs a backend code base using [uv](https://github.com/astral-sh/uv).
It also handles package caching using [`actions/cache`](https://github.com/actions/cache).

This action assumes:

* The codebase uses uv for dependency management.
* A `Makefile` provides an `install` target.
* The `Makefile` supports overriding `PYTHON_VERSION` and `PLONE_VERSION` via environment variables.

#### Inputs

* `python-version`: Python version to use.
* `plone-version`: Plone version to use.
* `working-directory`: Path to the backend code base.

#### Example usage

```yaml
- name: Setup backend codebase
  uses: plone/meta/.github/actions/setup_backend_uv@2.x
  with:
    python-version: 3.12
    plone-version: 6.1.1
    working-directory: backend
```

### `setup_frontend`

The action `setup_frontend` sets up and installs a frontend code base using [pnpm](https://pnpm.io/).
It also handles package caching using [`actions/cache`](https://github.com/actions/cache).

This action assumes:

* The code base uses pnpm for dependency management and was generated with [Cookieplone](https://github.com/plone/cookieplone).
* A `Makefile` provides an `install` target.

#### Inputs

* `node-version`: Node.js version to use.
* `working-directory`: Path to the frontend codebase.

#### Example usage

```yaml
- name: Setup frontend codebase
  uses: plone/meta/.github/actions/setup_frontend@2.x
  with:
    node-version: 22.x
    working-directory: frontend
```

### `setup_uv`

The action `setup_uv` sets up [uv](https://github.com/astral-sh/uv) and configures package caching.

This action assumes:

* The code base uses uv for dependency management.

#### Inputs

* `python-version`: Python version to use.
* `working-directory`: Path to the Python code base.

#### Example usage

```yaml
- name: Set up uv
  uses: plone/meta/.github/actions/setup_uv@2.x
  with:
    python-version: 3.12
    working-directory: docs
```

## Reusable workflows

Reusable workflows automate testing, building, documentation, and deployment tasks.
They are grouped into:

- **Backend workflows**: Python-based projects for Plone
- **Frontend workflows**: Node.js-based projects for Plone
- **Documentation workflows**: Building and validating documentation
- **Container workflows**: Building and publishing Docker images

Each workflow assumes the use of uv for Python-based projects or pnpm for Node.js-based projects for dependency management and standard Makefile targets.

### Backend workflows

The following sections describe the workflows for the Plone backend.


#### `backend-lint`

The workflow `backend-lint` lints and performs static analysis on a backend code base, including formatting, XML/ZCML validation, package metadata checking, Python version checking, and optional type checking.

##### Inputs

* `python-version`: Python version to use. Required.
* `plone-version`: Plone version to use. Required.
* `working-directory`: Path to the backend code base. Defaults to `.`.
* `check-typing`: Whether to run static typing checks using `mypy`. Defaults to `false`.
* `version-ruff`: Version of [ruff](https://github.com/astral-sh/ruff) to use. Defaults to `latest`.
* `version-zpretty`: Version of [zpretty](https://github.com/collective/zpretty) to use. Defaults to `latest`.
* `version-pyroma`: Version of [pyroma](https://github.com/regebro/pyroma) to use. Defaults to `latest`.
* `version-check-python`: Version of [check-python-versions](https://pypi.org/project/check-python-versions/) to use. Defaults to `latest`.

##### Example usage

```yaml
jobs:
  lint:
    name: "Backend: Lint"
    uses: plone/meta/.github/workflows/backend-lint.yml@2.x
    with:
      python-version: 3.12
      plone-version: 6.1.1
      working-directory: backend
```

#### `backend-pytest`

The workflow `backend-pytest` runs backend tests using [pytest](https://docs.pytest.org/en/stable/).

##### Inputs

* `python-version`: Python version to use. Required.
* `plone-version`: Plone version to use. Required.
* `working-directory`: Path to the backend code base. Defaults to `.`.

##### Example usage

```yaml
jobs:
  test:
    name: "Backend: Test"
    uses: plone/meta/.github/workflows/backend-pytest.yml@2.x
    with:
      python-version: 3.12
      plone-version: 6.1.1
      working-directory: backend
```

#### `backend-pytest-coverage`

The workflow `backend-pytest-coverage` runs backend tests and generates a coverage report with [coverage.py](https://coverage.readthedocs.io/en/latest/).

##### Inputs

* `python-version`: Python version to use. Required.
* `plone-version`: Plone version to use. Required.
* `working-directory`: Path to the backend code base. Defaults to `.`.

##### Example usage

```yaml
jobs:
  test:
    name: "Backend: Coverage"
    uses: plone/meta/.github/workflows/backend-pytest-coverage.yml@2.x
    with:
      python-version: 3.12
      plone-version: 6.1.1
      working-directory: backend
```

### Documentation workflows

The following sections describe the workflows for documentation.


#### `docs-build`

The workflow `docs-build` builds HTML documentation, checking for MyST syntax errors, and checks for broken links.
It also checks American English spelling, grammar, and syntax, and checks for compliance with the [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/) using [Vale](https://vale.sh/).

##### Inputs

* `python-version`: Python version to use. Defaults to `3.12`.
* `working-directory`: Path to the documentation scaffold. Defaults to `.`.
* `check-links`: Whether to run broken link checks. Defaults to `true`.
* `check-vale`: Whether to run Vale checks. Defaults to `true`.

##### Example usage

```yaml
jobs:
  docs:
    name: "Documentation"
    uses: plone/meta/.github/workflows/docs-build.yml@2.x
    with:
      python-version: 3.12
      working-directory: docs
      check-links: true
      check-vale: true
```


### Frontend workflows

The following sections describe the workflows for the Plone frontend.


#### `frontend-acceptance`

The workflow `frontend-acceptance` runs frontend acceptance tests using [Cypress](https://www.cypress.io/), including server startup and artifact uploads with screenshots and videos.

##### Inputs

* `node-version`: Node.js version to use. Required.
* `working-directory`: Path to the frontend code base. Defaults to `.`.

##### Example usage

```yaml
jobs:
  acceptance:
    name: "Frontend: Acceptance Tests"
    uses: plone/meta/.github/workflows/frontend-acceptance.yml@2.x
    with:
      node-version: 22.x
      working-directory: frontend
```

#### `frontend-code`

The workflow `frontend-code` runs static analysis, or linting, on a frontend code base.

##### Inputs

* `node-version`: Node.js version to use. Required.
* `working-directory`: Path to the frontend code base. Defaults to `.`.

##### Example usage

```yaml
jobs:
  qa:
    name: "Frontend: Code Analysis"
    uses: plone/meta/.github/workflows/frontend-code.yml@2.x
    with:
      node-version: 22.x
      working-directory: frontend
```

#### `frontend-i18n`

The workflow `frontend-i18n` validates that frontend translation files are up to date.

##### Inputs

* `node-version`: Node.js version to use. Required.
* `working-directory`: Path to the frontend code base. Defaults to `.`.

##### Example usage

```yaml
jobs:
  i18n:
    name: "Frontend: i18n Checks"
    uses: plone/meta/.github/workflows/frontend-i18n.yml@2.x
    with:
      node-version: 22.x
      working-directory: frontend
```

#### `frontend-storybook`

The workflow `frontend-storybook` builds Storybook documentation and optionally deploys it to GitHub Pages.

##### Inputs

* `node-version`: Node.js version to use. Required.
* `working-directory`: Path to the frontend code base. Defaults to `.`.
* `deploy`: Whether to deploy the Storybook build. Defaults to `false`.

##### Example usage

```yaml
jobs:
  storybook:
    name: "Frontend: Storybook"
    uses: plone/meta/.github/workflows/frontend-storybook.yml@2.x
    with:
      node-version: 22.x
      working-directory: frontend
      deploy: true
```

#### `frontend-unit`

The workflow `frontend-unit` runs unit tests on a frontend code base.

##### Inputs

* `node-version`: Node.js version to use. Required.
* `working-directory`: Path to the frontend code base. Defaults to `.`.

##### Example usage

```yaml
jobs:
  unit:
    name: "Frontend: Unit Tests"
    uses: plone/meta/.github/workflows/frontend-unit.yml@2.x
    with:
      node-version: 22.x
      working-directory: frontend
```

### Container workflows

The following sections describe the workflows for Plone container images.


#### `container-image-build-push`

The workflow `container-image-build-push` builds and optionally pushes a container image for use in tests or deployments.

##### Inputs

* `base-tag`: Base tag for the image, for example, `1.0.0`. Required.
* `working-directory`: Path to the project directory containing the Dockerfile. Defaults to `.`.
* `image-name-prefix`: Image name prefix, for example, the organization or repository name. Required.
* `image-name-suffix`: Image name suffix, for example, the service identifier. Required.
* `platforms`: Platforms for which to build the image. Defaults to `linux/amd64`.
* `dockerfile`: Relative path to the Dockerfile. Defaults to `Dockerfile`.
* `registry`: Container registry URL. Defaults to `ghcr.io`.
* `build-args`: Additional build arguments. Defaults to `""`.
* `push`: Whether to push the built image. Defaults to `true`.

##### Secrets

* `username`: Registry username. Required.
* `password`: Registry password. Required.

##### Example usage

```yaml
jobs:
  build-image:
    name: "Container: Build and Push"
    uses: plone/meta/.github/workflows/container-image-build-push.yml@2.x
    with:
      base-tag: 1.0.0
      working-directory: frontend
      image-name-prefix: ghcr.io/collective/collective-addon
      image-name-suffix: frontend
      platforms: linux/amd64
      dockerfile: Dockerfile
      registry: ghcr.io
      build-args: |
        VOLTO_VERSION=18.14.1
      push: true
    secrets:
      username: ${{ secrets.REGISTRY_USERNAME }}
      password: ${{ secrets.REGISTRY_PASSWORD }}
```

#### `container-image-build`

The workflow `container-image-build` builds a container image optimized for caching, typically used for internal tests, for example, acceptance tests.

##### Inputs

* `base-tag`: Base tag for the image. Required.
* `working-directory`: Path to the project directory containing the Dockerfile. Defaults to `.`.
* `image-name-prefix`: Image name prefix. Required.
* `image-name-suffix`: Image name suffix. Required.
* `image-cache-suffix`: Suffix for naming cache images. Defaults to `buildcache`.
* `platforms`: Platforms for which to build the image. Defaults to `linux/amd64`.
* `dockerfile`: Relative path to the Dockerfile. Defaults to `Dockerfile`.
* `registry`: Container registry URL. Defaults to `ghcr.io`.
* `build-args`: Additional build arguments. Defaults to `""`.
* `cache-key`: Cache identification key. Defaults to the branch name, for example, `github.ref_name`.

##### Secrets

* `username`: Registry username. Required.
* `password`: Registry password. Required.

##### Example usage

```yaml
jobs:
  build-image:
    name: "Container: Build Only"
    uses: plone/meta/.github/workflows/container-image-build.yml@2.x
    with:
      base-tag: branch-x
      working-directory: backend
      image-name-prefix: ghcr.io/collective/collective-addon
      image-name-suffix: backend
      image-cache-suffix: buildcache
      platforms: linux/amd64
      dockerfile: Dockerfile
      registry: ghcr.io
      build-args: |
        PLONE_VERSION=6.1.1
      cache-key: branch-x
    secrets:
      username: ${{ secrets.REGISTRY_USERNAME }}
      password: ${{ secrets.REGISTRY_PASSWORD }}
```

#### `container-image-push`

The workflow `container-image-push` builds and pushes a container image to a registry, generating multiple tags based on branch, commit, and semantic versioning.

##### Inputs

* `base-tag`: Base tag for the image. Required.
* `working-directory`: Path to the project directory containing the Dockerfile. Defaults to `.`.
* `image-name-prefix`: Image name prefix. Required.
* `image-name-suffix`: Image name suffix. Required.
* `image-cache-suffix`: Suffix for naming cache images. Defaults to `buildcache`.
* `platforms`: Platforms for which to build the image. Defaults to `linux/amd64`.
* `dockerfile`: Relative path to the Dockerfile. Defaults to `Dockerfile`.
* `registry`: Container registry URL. Defaults to `ghcr.io`.
* `build-args`: Additional build arguments. Defaults to `""`.
* `cache-key`: Cache identification key. Defaults to the branch name, for example, `github.ref_name`.

##### Secrets

* `username`: Registry username. Required.
* `password`: Registry password. Required.

##### Example usage

```yaml
jobs:
  publish-image:
    name: "Container: Build and Push"
    uses: plone/meta/.github/workflows/container-image-push.yml@2.x
    with:
      base-tag: branch-x
      working-directory: backend
      image-name-prefix: ghcr.io/collective/collective-addon
      image-name-suffix: backend
      image-cache-suffix: buildcache
      platforms: linux/amd64
      dockerfile: Dockerfile
      registry: ghcr.io
      build-args: |
        PLONE_VERSION=6.1.1
      cache-key: branch-x
    secrets:
      username: ${{ secrets.REGISTRY_USERNAME }}
      password: ${{ secrets.REGISTRY_PASSWORD }}
```
