gha-utils 4.0.1__tar.gz → 4.0.2__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Potentially problematic release.


This version of gha-utils might be problematic. Click here for more details.

@@ -0,0 +1,286 @@
1
+ Metadata-Version: 2.1
2
+ Name: gha-utils
3
+ Version: 4.0.2
4
+ Summary: ⚙️ CLI helpers for GitHub Actions + reuseable workflows
5
+ Author-email: Kevin Deldycke <kevin@deldycke.com>
6
+ Project-URL: Homepage, https://github.com/kdeldycke/workflows
7
+ Project-URL: Repository, https://github.com/kdeldycke/workflows
8
+ Project-URL: Funding, https://github.com/sponsors/kdeldycke
9
+ Project-URL: Issues, https://github.com/kdeldycke/workflows/issues
10
+ Project-URL: Changelog, https://github.com/kdeldycke/workflows/blob/main/changelog.md
11
+ Keywords: build-automation,changelog-formatter,ci-cd,cli,formatting,github-actions,labels,linting,markdown,mypy,nuitka,packaging,pypi,python,release-automation,sphinx,sponsorship,terminal,typo,workflow-reusable,yaml
12
+ Classifier: Development Status :: 5 - Production/Stable
13
+ Classifier: Environment :: Console
14
+ Classifier: Framework :: Sphinx
15
+ Classifier: Framework :: Pelican
16
+ Classifier: Intended Audience :: Developers
17
+ Classifier: License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)
18
+ Classifier: Operating System :: MacOS :: MacOS X
19
+ Classifier: Operating System :: Microsoft :: Windows
20
+ Classifier: Operating System :: POSIX :: Linux
21
+ Classifier: Programming Language :: Python :: 3
22
+ Classifier: Programming Language :: Python :: 3.8
23
+ Classifier: Programming Language :: Python :: 3.9
24
+ Classifier: Programming Language :: Python :: 3.10
25
+ Classifier: Programming Language :: Python :: 3.11
26
+ Classifier: Programming Language :: Python :: 3.12
27
+ Classifier: Programming Language :: Python :: Implementation :: CPython
28
+ Classifier: Programming Language :: Unix Shell
29
+ Classifier: Topic :: Documentation :: Sphinx
30
+ Classifier: Topic :: File Formats :: JSON
31
+ Classifier: Topic :: Security
32
+ Classifier: Topic :: Software Development :: Build Tools
33
+ Classifier: Topic :: Software Development :: Compilers
34
+ Classifier: Topic :: Software Development :: Documentation
35
+ Classifier: Topic :: Software Development :: Libraries :: Python Modules
36
+ Classifier: Topic :: Software Development :: Quality Assurance
37
+ Classifier: Topic :: Software Development :: Version Control :: Git
38
+ Classifier: Topic :: System :: Archiving :: Packaging
39
+ Classifier: Topic :: System :: Installation/Setup
40
+ Classifier: Topic :: System :: Shells
41
+ Classifier: Topic :: System :: Software Distribution
42
+ Classifier: Topic :: Terminals
43
+ Classifier: Topic :: Text Processing :: Markup :: HTML
44
+ Classifier: Topic :: Text Processing :: Markup :: Markdown
45
+ Classifier: Topic :: Utilities
46
+ Classifier: Typing :: Typed
47
+ Requires-Python: >=3.8
48
+ Description-Content-Type: text/markdown
49
+ Requires-Dist: black~=24.4.2
50
+ Requires-Dist: bump-my-version~=0.24.0
51
+ Requires-Dist: click-extra~=4.8.3
52
+ Requires-Dist: mypy~=1.10.0
53
+ Requires-Dist: packaging~=24.1
54
+ Requires-Dist: PyDriller~=2.6
55
+ Requires-Dist: pyproject-metadata~=0.8.0
56
+ Requires-Dist: tomli~=2.0.1; python_version < "3.11"
57
+ Requires-Dist: wcmatch~=8.5.2
58
+
59
+ # `gha-utils` CLI + reusable workflows
60
+
61
+ [![Last release](https://img.shields.io/pypi/v/gha-utils.svg)](https://pypi.python.org/pypi/gha-utils)
62
+ [![Python versions](https://img.shields.io/pypi/pyversions/gha-utils.svg)](https://pypi.python.org/pypi/gha-utils)
63
+ [![Type checked with mypy](http://www.mypy-lang.org/static/mypy_badge.svg)](http://mypy-lang.org/)
64
+ [![Unittests status](https://github.com/kdeldycke/workflows/actions/workflows/tests.yaml/badge.svg?branch=main)](https://github.com/kdeldycke/workflows/actions/workflows/tests.yaml?query=branch%3Amain)
65
+
66
+ `gha-utils` stands for **G**it**H**ub **A**ction workflows **Util**itie**s**.
67
+
68
+ Maintaining project takes time. This repository contains the code of the `gha-utils` CLI and a collection of reusable workflows to:
69
+
70
+ - maintain a Python project, its CLI, doc, QA, etc.
71
+ - maintain an Awesome List project.
72
+
73
+ ## `gha-utils` CLI
74
+
75
+ ### Executables
76
+
77
+ Standalone executables of `gha-utils`'s latest version are available as direct downloads for several platforms and architectures:
78
+
79
+ | Platform | `x86_64` | `arm64` |
80
+ | ----------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
81
+ | **Linux** | [Download `gha-utils-linux-x64.bin`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-linux-x64.bin) | |
82
+ | **macOS** | [Download `gha-utils-macos-x64.bin`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-macos-x64.bin) | [Download `gha-utils-macos-arm64.bin`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-macos-arm64.bin) |
83
+ | **Windows** | [Download `gha-utils-windows-x64.exe`](https://github.com/kdeldycke/workflows/releases/latest/download/gha-utils-windows-x64.exe) | |
84
+
85
+ ### Run dev version
86
+
87
+ ```shell-session
88
+ $ git clone https://github.com/kdeldycke/workflows
89
+ $ cd workflows
90
+ $ python -m pip install uv
91
+ $ uv venv
92
+ $ source .venv/bin/activate
93
+ $ uv pip install .
94
+ $ uv run gha-utils
95
+ ```
96
+
97
+ ## Reusable workflows collection
98
+
99
+ This repository contains workflows to automate most of the boring tasks.
100
+
101
+ These workflows are mostly used for Python projects and their documentation, but not only. They're all [reusable GitHub actions workflows](https://docs.github.com/en/actions/learn-github-actions/reusing-workflows).
102
+
103
+ Reasons for a centralized workflow repository:
104
+
105
+ - reusability of course: no need to update dozens of repository where 95% of workflows are the same
106
+ - centralize all dependencies pertaining to automation: think of the point-release of an action that triggers dependabot upgrade to all your repositories depending on it
107
+
108
+ ### Guidelines
109
+
110
+ I don't want to copy-n-past, keep in sync and maintain another `N`th CI/CD file at the root of my repositories.
111
+
112
+ So my policy is: move every repository-specific config in a `pyproject.toml` file, or hide the gory details in a reused workflow.
113
+
114
+ ### `.github/workflows/docs.yaml` jobs
115
+
116
+ - Autofix typos
117
+
118
+ - Optimize images
119
+
120
+ - Keep `.mailmap` up to date
121
+
122
+ - Update dependency graph of Python projects
123
+
124
+ - **Requires**:
125
+ - Python package with a `pyproject.toml` file
126
+
127
+ - Build Sphinx-based documentation and publish it to GitHub Pages
128
+
129
+ - **Requires**:
130
+ - Python package with a `pyproject.toml` file
131
+ - All Sphinx dependencies in a `docs` [extra dependency group](https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#dependencies-and-requirements):
132
+ ```toml
133
+ [project.optional-dependencies]
134
+ docs = [
135
+ "furo == 2024.1.29",
136
+ "myst-parser ~= 3.0.0",
137
+ "sphinx >= 6",
138
+ ...
139
+ ]
140
+ ```
141
+ - Sphinx configuration file at `docs/conf.py`
142
+
143
+ - Sync awesome projects from `awesome-template` repository
144
+
145
+ ### Why all these `requirements/*.txt` files?
146
+
147
+ Let's look for example at the `lint-yaml` job from [`.github/workflows/lint.yaml`](https://github.com/kdeldycke/workflows/blob/main/.github/workflows/lint.yaml#L126). Here we only need the `yamllint` CLI. This CLI is [distributed on PyPi](https://pypi.org/project/yamllint/). So before executing it, we could have simply run the following step:
148
+
149
+ ```yaml
150
+ - name: Install yamllint
151
+ run: |
152
+ pip install yamllint
153
+ ```
154
+
155
+ Instead, we install it via the [`requirements/yamllint.txt` file](https://github.com/kdeldycke/workflows/blob/main/requirements/yamllint.txt).
156
+
157
+ Why? Because I want the version of `yamllint` to be pinned. By pinning it, I make the workflow stable, predictable and reproducible.
158
+
159
+ So why use a dedicated requirements file? Why don't we simply add the version? Like this:
160
+
161
+ ```yaml
162
+ - name: Install yamllint
163
+ run: |
164
+ pip install yamllint==1.35.1
165
+ ```
166
+
167
+ That would indeed pin the version. But it requires the maintainer (me) to keep track of new release and update manually the version string. That's a lot of work. And I'm lazy. So this should be automated.
168
+
169
+ To automate that, the only practical way I found was to rely on dependabot. But dependabot cannot update arbitrary versions in `run:` YAML blocks. It [only supports `requirements.txt` and `pyproject.toml`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#pip-and-pip-compile) files for Python projects.
170
+
171
+ So to keep track of new versions of dependencies while keeping them stable, we've hard-coded all Python libraries and CLIs in the `requirements/*.txt` files. All with pinned versions.
172
+
173
+ And for the case we need to install all dependencies in one go, we have a [`requirements.txt` file at the root](https://github.com/kdeldycke/workflows/blob/main/requirements.txt) that is referencing all files from the `requirements/` subfolder.
174
+
175
+ ### Permissions and token
176
+
177
+ This repository updates itself via GitHub actions. It particularly updates its own YAML files in `.github/workflows`. That's forbidden by default. So we need extra permissions.
178
+
179
+ Usually, to grant special permissions to some jobs, you use the [`permissions` parameter in workflow](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) files. It looks like this:
180
+
181
+ ```yaml
182
+ on: (...)
183
+
184
+ jobs:
185
+
186
+ my-job:
187
+ runs-on: ubuntu-latest
188
+ permissions:
189
+ contents: write
190
+ pull-requests: write
191
+
192
+ steps: (...)
193
+ ```
194
+
195
+ But the `contents: write` permission doesn't allow write access to the workflow files in the `.github` subfolder. There is `actions: write`, but it only covers workflow runs, not their YAML source file. Even a `permissions: write-all` doesn't work. So you cannot use the `permissions` parameter to allow a repository's workflow update its own workflow files.
196
+
197
+ You will always end up with this kind or errors:
198
+
199
+ ```text
200
+ ! [remote rejected] branch_xxx -> branch_xxx (refusing to allow a GitHub App to create or update workflow `.github/workflows/my_workflow.yaml` without `workflows` permission)
201
+
202
+ error: failed to push some refs to 'https://github.com/kdeldycke/my-repo'
203
+ ```
204
+
205
+ > \[!NOTE\]
206
+ > That's also why the Settings > Actions > General > Workflow permissions parameter on your repository has no effect on this issue, even with the `Read and write permissions` set:
207
+ > ![](docs/assets/repo-workflow-permissions.png)
208
+
209
+ To bypass the limitation, we rely on a custom access token. By convention, we call it `WORKFLOW_UPDATE_GITHUB_PAT`. It will be used, [in place of the default `secrets.GITHUB_TOKEN`](https://github.com/search?q=repo%3Akdeldycke%2Fworkflows%20WORKFLOW_UPDATE_GITHUB_PAT&type=code), in steps in which we need to change the workflow YAML files.
210
+
211
+ To create this custom `WORKFLOW_UPDATE_GITHUB_PAT`:
212
+
213
+ - From your GitHub user, go to `Settings` > `Developer Settings` > `Personal Access Tokens` > `Fine-grained tokens`
214
+ - Click on the `Generate new token` button
215
+ - Choose a good token name like `workflow-self-update` to make your intention clear
216
+ - Choose `Only select repositories` and the list the repositories in needs of updating their workflow YAML files
217
+ - In the `Repository permissions` drop-down, sets:
218
+ - `Contents`: `Access: **Read and Write**`
219
+ - `Metadata` (mandatory): `Access: **Read-only**`
220
+ - `Pull Requests`: `Access: **Read and Write**`
221
+ - `Workflows`: `Access: **Read and Write**`
222
+ > \[!NOTE\]
223
+ > This is the only place where I can have control over the `Workflows` permission, which is not supported by the `permissions:` parameter in YAML files.
224
+ - Now save these parameters and copy the `github_pat_XXXX` secret token
225
+ - Got to your repo > `Settings` > `Security` > `Secrets and variables` > `Actions` > `Secrets` > `Repository secrets` and click `New repository secrets`
226
+ - Name your secret `WORKFLOW_UPDATE_GITHUB_PAT` and copy the `github_pat_XXXX` token in the `Secret` field
227
+
228
+ Now re-run your actions and they should be able to update the workflow files in `.github` folder without the `refusing to allow a GitHub App to create or update workflow` error.
229
+
230
+ ### Release management
231
+
232
+ It turns out [Release Engineering is a full-time job, and full of edge-cases](https://blog.axo.dev/2023/02/cargo-dist).
233
+
234
+ Rust has [`cargo-dist`](https://github.com/axodotdev/cargo-dist). Go has... ? But there is no equivalent for Python.
235
+
236
+ So I made up a [`release.yaml` workflow](https://github.com/kdeldycke/workflows/blob/main/.github/workflows/release.yaml), which:
237
+
238
+ 1. Extracts project metadata from `pyproject.toml`
239
+ 1. Generates a build matrix of all commits / os / arch / CLI entry points
240
+ 1. Build Python wheel with Twine
241
+ 1. Compile binaries of all CLI with Nuitka
242
+ 1. Tag the release commit in Git
243
+ 1. Publish new version to PyPi
244
+ 1. Publish a GitHub release
245
+ 1. Attach and rename build artifacts to it
246
+
247
+ ## Changelog
248
+
249
+ A [detailed changelog](changelog.md) is available.
250
+
251
+ ## Used in
252
+
253
+ Check these projects to get real-life examples of usage and inspiration:
254
+
255
+ - ![GitHub stars](https://img.shields.io/github/stars/kdeldycke/awesome-falsehood?label=%E2%AD%90&style=flat-square) [Awesome Falsehood](https://github.com/kdeldycke/awesome-falsehood#readme) - Falsehoods Programmers Believe in.
256
+ - ![GitHub stars](https://img.shields.io/github/stars/kdeldycke/awesome-engineering-team-management?label=%E2%AD%90&style=flat-square) [Awesome Engineering Team Management](https://github.com/kdeldycke/awesome-engineering-team-management#readme) - How to transition from software development to engineering management.
257
+ - ![GitHub stars](https://img.shields.io/github/stars/kdeldycke/awesome-iam?label=%E2%AD%90&style=flat-square) [Awesome IAM](https://github.com/kdeldycke/awesome-iam#readme) - Identity and Access Management knowledge for cloud platforms.
258
+ - ![GitHub stars](https://img.shields.io/github/stars/kdeldycke/awesome-billing?label=%E2%AD%90&style=flat-square) [Awesome Billing](https://github.com/kdeldycke/awesome-billing#readme) - Billing & Payments knowledge for cloud platforms.
259
+ - ![GitHub stars](https://img.shields.io/github/stars/kdeldycke/meta-package-manager?label=%E2%AD%90&style=flat-square) [Meta Package Manager](https://github.com/kdeldycke/meta-package-manager#readme) - A unifying CLI for multiple package managers.
260
+ - ![GitHub stars](https://img.shields.io/github/stars/kdeldycke/mail-deduplicate?label=%E2%AD%90&style=flat-square) [Mail Deduplicate](https://github.com/kdeldycke/mail-deduplicate#readme) - A CLI to deduplicate similar emails.
261
+ - ![GitHub stars](https://img.shields.io/github/stars/kdeldycke/dotfiles?label=%E2%AD%90&style=flat-square) [dotfiles](https://github.com/kdeldycke/dotfiles#readme) - macOS dotfiles for Python developers.
262
+ - ![GitHub stars](https://img.shields.io/github/stars/kdeldycke/click-extra?label=%E2%AD%90&style=flat-square) [Click Extra](https://github.com/kdeldycke/click-extra#readme) - Extra colorization and configuration loading for Click.
263
+ - ![GitHub stars](https://img.shields.io/github/stars/themagicalmammal/wikibot?label=%E2%AD%90&style=flat-square) [Wiki bot](https://github.com/themagicalmammal/wikibot#readme) - A bot which provides features from Wikipedia like summary, title searches, location API etc.
264
+ - ![GitHub stars](https://img.shields.io/github/stars/kdeldycke/workflows?label=%E2%AD%90&style=flat-square) [workflows](https://github.com/kdeldycke/workflows#readme) - Itself. Eat your own dog-food.
265
+ - ![GitHub stars](https://img.shields.io/github/stars/themagicalmammal/stock-analyser?label=%E2%AD%90&style=flat-square) [Stock Analysis](https://github.com/themagicalmammal/stock-analyser#readme) - Simple to use interfaces for basic technical analysis of stocks.
266
+ - ![GitHub stars](https://img.shields.io/github/stars/themagicalmammal/genetictabler?label=%E2%AD%90&style=flat-square) [GeneticTabler](https://github.com/themagicalmammal/genetictabler#readme) - Time Table Scheduler using Genetic Algorithms.
267
+ - ![GitHub stars](https://img.shields.io/github/stars/themagicalmammal/excel-write?label=%E2%AD%90&style=flat-square) [Excel Write](https://github.com/themagicalmammal/excel-write#readme) - Optimised way to write in excel files.
268
+
269
+ Feel free to send a PR to add your project in this list if you are relying on these scripts.
270
+
271
+ ## Release process
272
+
273
+ All steps of the release process and version management are automated in the
274
+ [`changelog.yaml`](https://github.com/kdeldycke/workflows/blob/main/.github/workflows/changelog.yaml)
275
+ and
276
+ [`release.yaml`](https://github.com/kdeldycke/workflows/blob/main/.github/workflows/release.yaml)
277
+ workflows.
278
+
279
+ All there's left to do is to:
280
+
281
+ - [check the open draft `prepare-release` PR](https://github.com/kdeldycke/workflows/pulls?q=is%3Apr+is%3Aopen+head%3Aprepare-release)
282
+ and its changes,
283
+ - click the `Ready for review` button,
284
+ - click the `Rebase and merge` button,
285
+ - let the workflows tag the release and set back the `main` branch into a
286
+ development state.
@@ -17,4 +17,4 @@
17
17
 
18
18
  from __future__ import annotations
19
19
 
20
- __version__ = "4.0.1"
20
+ __version__ = "4.0.2"
@@ -38,9 +38,11 @@ class Changelog:
38
38
  self.content = initial_changelog
39
39
  logging.debug(f"Initial content set to:\n{self.content}")
40
40
 
41
- def update(self) -> str:
41
+ def update(self) -> str | None:
42
42
  r"""Adds a new empty entry at the top of the changelog.
43
43
 
44
+ Returns ``None`` if initial changelog content has already been updated.
45
+
44
46
  This is designed to be used just after a new release has been tagged. And before a
45
47
  post-release version increment is applied with a call to:
46
48
 
@@ -145,7 +147,9 @@ class Changelog:
145
147
 
146
148
  logging.info("New generated section:\n" + indent(new_entry, " " * 2))
147
149
 
148
- assert new_entry not in history
150
+ # No need to update.
151
+ if new_entry in history:
152
+ return None
149
153
 
150
154
  # Recompose full changelog with new top entry.
151
155
  return f"{changelog_header}{new_entry}{history}"
@@ -25,6 +25,7 @@ from pathlib import Path
25
25
 
26
26
  from click_extra import (
27
27
  Choice,
28
+ Context,
28
29
  argument,
29
30
  extra_group,
30
31
  file_path,
@@ -55,6 +56,15 @@ def file_writer(filepath):
55
56
  writer.close()
56
57
 
57
58
 
59
+ def get_header(ctx: Context):
60
+ """Generates metadata to be leaved as comments to the top of a file generated by this CLI."""
61
+ return (
62
+ f"# Generated by {ctx.command_path} v{__version__}"
63
+ " - https://github.com/kdeldycke/workflows\n"
64
+ f"# Timestamp: {datetime.now().isoformat()}.\n\n"
65
+ )
66
+
67
+
58
68
  @extra_group
59
69
  def gha_utils():
60
70
  pass
@@ -114,20 +124,16 @@ def metadata(ctx, format, overwrite, output_path):
114
124
  env_file = os.getenv("GITHUB_OUTPUT")
115
125
  if env_file and Path(env_file) != output_path:
116
126
  logging.warning(
117
- "Output path is not the same as $GITHUB_OUTPUT environment variable, which is generally what we're looking to do in GitHub CI runners for other jobs to consume the produced metadata."
127
+ "Output path is not the same as $GITHUB_OUTPUT environment variable,"
128
+ " which is generally what we're looking to do in GitHub CI runners for"
129
+ " other jobs to consume the produced metadata."
118
130
  )
119
131
 
120
132
  dialect = Dialects(format)
121
133
  content = metadata.dump(dialect=dialect)
122
134
 
123
135
  with file_writer(output_path) as f:
124
- f.write(
125
- # Leave some metadata as comment.
126
- f"# Generated by {ctx.command_path} v{__version__}"
127
- " - https://github.com/kdeldycke/workflows.\n"
128
- f"# Timestamp: {datetime.now().isoformat()}.\n"
129
- f"{content}"
130
- )
136
+ f.write(content)
131
137
 
132
138
 
133
139
  @gha_utils.command(short_help="Maintain a Markdown-formatted changelog")
@@ -147,10 +153,13 @@ def changelog(ctx, source, changelog_path):
147
153
  initial_content = None
148
154
  if source:
149
155
  logging.info(f"Read initial changelog from {source}")
150
- initial_content = source.read_text()
156
+ initial_content = source.read_text(encoding="utf-8")
151
157
 
152
158
  changelog = Changelog(initial_content)
153
159
  content = changelog.update()
160
+ if not content:
161
+ logging.warning("Changelog already up to date. Do nothing.")
162
+ ctx.exit()
154
163
 
155
164
  if is_stdout(changelog_path):
156
165
  logging.info(f"Print updated results to {sys.stdout.name}")
@@ -189,7 +198,7 @@ def mailmap(ctx, source, updated_mailmap):
189
198
  initial_content = None
190
199
  if source:
191
200
  logging.info(f"Read initial mapping from {source}")
192
- initial_content = source.read_text()
201
+ initial_content = source.read_text(encoding="utf-8")
193
202
 
194
203
  mailmap = Mailmap(initial_content)
195
204
  content = mailmap.updated_map()
@@ -200,10 +209,4 @@ def mailmap(ctx, source, updated_mailmap):
200
209
  logging.info(f"Save updated results to {updated_mailmap}")
201
210
 
202
211
  with file_writer(updated_mailmap) as f:
203
- f.write(
204
- # Leave some metadata as comment.
205
- f"# Generated by {ctx.command_path} v{__version__}"
206
- " - https://github.com/kdeldycke/workflows.\n"
207
- f"# Timestamp: {datetime.now().isoformat()}.\n\n"
208
- f"{content}"
209
- )
212
+ f.write(f"{get_header(ctx)}{content}")
@@ -68,7 +68,7 @@ class Mailmap:
68
68
 
69
69
  logging.debug(
70
70
  "Authors and committers found in Git history:\n"
71
- f"{'\n'.join(sorted(contributors, key=str.casefold))}"
71
+ + "\n".join(sorted(contributors, key=str.casefold))
72
72
  )
73
73
  return contributors
74
74
 
@@ -94,6 +94,7 @@ class Mailmap:
94
94
 
95
95
  # Render content in .mailmap format.
96
96
  return (
97
- f"{'\n'.join(header_comments)}\n\n"
98
- f"{'\n'.join(sorted(mappings, key=str.casefold))}\n"
97
+ "\n".join(header_comments)
98
+ + "\n\n"
99
+ + "\n".join(sorted(mappings, key=str.casefold))
99
100
  )
@@ -466,7 +466,7 @@ class Metadata:
466
466
  ``pyproject.toml`` exists and respects the standards. ``False`` otherwise.
467
467
  """
468
468
  if self.pyproject_path.exists() and self.pyproject_path.is_file():
469
- toml = tomllib.loads(self.pyproject_path.read_text())
469
+ toml = tomllib.loads(self.pyproject_path.read_text(encoding="utf-8"))
470
470
  try:
471
471
  metadata = StandardMetadata.from_pyproject(toml)
472
472
  self._is_python_project = True
@@ -940,9 +940,13 @@ class Metadata:
940
940
  # Generate a link to the version of the package published on PyPi.
941
941
  pypi_link = ""
942
942
  if self.package_name:
943
- pypi_link = f"[🐍 Available on PyPi](https://pypi.org/project/{
944
- self.package_name
945
- }/{version})."
943
+ pypi_link = (
944
+ "[🐍 Available on PyPi](https://pypi.org/project/"
945
+ + self.package_name
946
+ + "/"
947
+ + version
948
+ + ")."
949
+ )
946
950
 
947
951
  # Assemble the release notes.
948
952
  return f"{changes}\n\n{pypi_link}".strip()
@@ -1009,7 +1013,7 @@ class Metadata:
1009
1013
  }
1010
1014
 
1011
1015
  logging.debug(f"Raw metadata: {metadata!r}")
1012
- logging.debug(f"Format metadata into {dialect} dialect.")
1016
+ logging.debug(f"Format metadata into {dialect} format.")
1013
1017
 
1014
1018
  content = ""
1015
1019
  if dialect == Dialects.GITHUB:
@@ -1027,6 +1031,6 @@ class Metadata:
1027
1031
  assert dialect == Dialects.PLAIN
1028
1032
  content = repr(metadata)
1029
1033
 
1030
- logging.debug(f"Formatted metadata: {content}")
1034
+ logging.debug(f"Formatted metadata:\n{content}")
1031
1035
 
1032
1036
  return content