ozi-project/ozi

Python project packaging for Meson.

OZI

OZI is a set of publishing tools for creating and maintaining Python packages. See the documentation for the project roadmap, API specification, Meson version support, and other project information.

Project Information

Purpose

OZI is meant for Python developers as a standardized and opinionated Python packaging style guide. It consists of command line utilities and a continuous integration checkpointing API using the Meson build system.

The OZI continuous integration strategy consists of:

1. The following isolated checkpoint environments:

• code testing and coverage
• distributing Python packages with Meson
• code linting and formatting

2. Release drafting
3. Building of releases
4. Provenance generation (SLSA v1.0 - Level 3)
5. Publishing

What OZI is not

• A replacement for test environment managers like tox, as a matter of fact OZI uses tox.
• A replacement for git hook package management tools like pre-commit

What OZI is

• Checkpointed Python packaging for Meson projects focused on pure Python sources.

Contributing

See the project CONTRIBUTING.md

Contact

Eden Ross Duff MSc - [email protected]

ozi's Issues

Single checkpoint suite selected but all suites downloaded

This bug was introduced during a refactor of the main meson.build and is a regression as it is not intended behavior.

Checkpoint is really bloated

It takes over 300 seconds to run checkpoints per python version.

Describe the solution you'd like
Rewrite OZI-Project/checkpoint and the corresponding template to use tox-gh entrypoints as intended. That is, just running a single workflow job per Python version and running the default checkpoints. This will also entail adding some workflow output that is basically the tail of the meson test output per checkpoint.

OZI builds empty wheels without warning in a dirty repository or untagged commit

OZI drafts empty wheels without warning in a dirty repository or untagged commit.

python -m build -w

The above command creates a wheel with the correct version scheme in dist/ with the correct metadata, however, the package sources are totally absent. This is the exact command used in the default OZI continuous integration toolchain. It violates the principle of least surprise to not raise an error in this case.

I would like it if OZI's backend wheel entrypoint would fail with an error instead.
At minimum it should warn the user. I kind of like that any build has to be tagged as full release or prerelease to actually make something. The checkpoints run on a local version and then the commit gets tagged which lets the rest of the packaging stuff work as normal. It packages the binary as expected based on the local version source that got checkpointed and signed then the actual package is signed. It kind of scares me that it does feel somewhat arcane when running the same commands outside of a tagged commit just gives you an empty package.

Duplicated license templates

Is your feature request related to a problem? Please describe.
ozi/templates/license/** contains several duplicate license texts.

Describe the solution you'd like
I would like to have a collection of root license templates to extend as necessary.

Fix and vendor ``pyc_wheel``

Describe the bug
pyc_wheel has an unfixed zipslip vulnerability.

We should vendor the fixed fork we maintain @OZI-Project/fork.

Fix "method_complexity" issue in ozi/new/__main__.py

Function maintainer_email has a Cognitive Complexity of 11 (exceeds 5 allowed). Consider refactoring.

https://codeclimate.com/github/OZI-Project/OZI/ozi/new/__main__.py#issue_659c1d6d26b87c00010000ff

Fix "file_lines" issue in ozi/fix/__main__.py

File __main__.py has 578 lines of code (exceeds 250 allowed). Consider refactoring.

https://codeclimate.com/github/OZI-Project/OZI/ozi/fix/__main__.py#issue_659c1d6d26b87c0001000104

Our Python distribution support keys are incorrect

Our Python distribution support keys are incorrect.
There is only ever a single bugfix release.
See: https://devguide.python.org/versions/ for more information.

Proposed Solution

OZI (ozi.spec)

• Rename security to security2
• Rename bugfix2 to security1
• Rename bugfix1 to bugfix
• Bump spec CI workflow versions:
  • draft
  • release
• Feature bump

blastpipe (blastpipe.ozi_templates)

• Rename security to security2
• Rename bugfix2 to security1
• Rename bugfix1 to bugfix
• Bump workflow versions:
  • draft
  • release
• Feature bump

draft

• Rename security to security2
• Rename bugfix2 to security1
• Rename bugfix1 to bugfix
• Bump minor version to 0.3

release

• Rename security to security2
• Rename bugfix2 to security1
• Rename bugfix1 to bugfix
• Bump minor version to 0.7

docs

• Rename security to security2
• Rename bugfix2 to security1
• Rename bugfix1 to bugfix

``ozi``, ``ozi-fix``, and ``ozi-new`` should share an entrypoint.

Spec should pin workflow versions

Fix "method_complexity" issue in ozi/fix/__main__.py

Function walk_build_definition has a Cognitive Complexity of 19 (exceeds 5 allowed). Consider refactoring.

https://codeclimate.com/github/OZI-Project/OZI/ozi/fix/__main__.py#issue_659c1d6d26b87c0001000107

Fix "method_complexity" issue in ozi/fix/__main__.py

Function walk_build_definition has a Cognitive Complexity of 19 (exceeds 5 allowed). Consider refactoring.

https://codeclimate.com/github/OZI-Project/OZI/ozi/fix/__main__.py#issue_659c1d6d26b87c0001000107

Integrate HypoFuzz runner.

Tracking issue for:

• https://github.com/OZI-Project/OZI/security/code-scanning/13

Add rst-lint back to the lint utilities.

The lint checkpoint, and checkpoints in general, are to check that a project can be packaged, released, and published. Twine will fail to upload bad readme text and we should not be letting this happen.

This can't catch every issue see https://pypi.org/project/restructuredtext-lint/:

While a document may lint cleanly locally, there can be issues when submitted it to [PyPI](http://pypi.python.org/). Here are some common problems:

    Usage of non-builtin lexers (e.g. bibtex) will pass locally but not be recognized/parsable on [PyPI](http://pypi.python.org/)

        This is due to [PyPI](http://pypi.python.org/) not having a non-builtin lexer installed

        Please avoid non-builtin lexers to avoid complications

        For more information, see [#27](https://github.com/twolfson/restructuredtext-lint/issues/27)

    Relative hyperlinks will not work (e.g. ./UNLICENSE)

        According to Stack Overflow, hyperlinks must use a scheme (e.g. http, https) and that scheme must be whitelisted

            http://stackoverflow.com/a/16594755

        Please use absolute hyperlinks (e.g. https://github.com/twolfson/restructuredtext-lint/blob/master/UNLICENSE)

However, these are fair restrictions to have on a shared README file.

How do we handle style changes in formatters?

          This is not merging due to style changes in black 24.1.0

Originally posted by @rjdbcm in #118 (comment)

Fix "file_lines" issue in ozi/spec.py

File spec.py has 760 lines of code (exceeds 250 allowed). Consider refactoring.

https://codeclimate.com/github/OZI-Project/OZI/ozi/spec.py#issue_659c1d6d26b87c00010000f5

Test ticket from Code Climate

checkpoint utilities install failure CPython 3.13

It looks like we are waiting on the rust components of the toolchain to support CPython 3.13.
In dist:

pydantic-core - via python-semantic-release(dist:semantic-release)

In test:

crosshair-tool - via hypothesis(test:plugin-only:hypothesis)

---

There are also component utilities that depend on the pre-CPython 3.13 CFFI.

In lint:

cmarkgfm - via readme-renderer[md](lint:readme-renderer)

Finalize build backend

Is your feature request related to a problem? Please describe.
The PyPI version (0.2) of mesonpep517 has a number of issues.
Options don't pass through build properly for one.

Describe the solution you'd like
Use our vendored version with a few fixes.

Alternatives to consider

• Use the official @mesonbuild/meson-python build backend.
• Use mesonpep517 but allow for future replacement.

Packages named like ``X.X*``, ``X-X*`` or ``X_X*`` fail wheel builds

ozi-new created projects with names like X.X*, X-X* or X_X* completely breaks our wheel builds.
This issue is likely caused by mesonpep517 and demonstrated in our own OZI.build and ozi-template repos.

Project-URLs are not supported by OZI

Issue Description

OZI doesn't provide a Project-URL user input.

Proposed Solution

Add a --project-url (Multiple use) argument to ozi-new

Alternate Solution

None

OZI meson.build configuration step overwrites pyproject.toml.

Config writing should never edit build folder files in place. This was discovered with StepSecurity.

OZI does not support Markdown

Issue Description

OZI does not support Markdown in ozi-new project ...

Proposed Solution

Provide a Markdown README template and allow users to select the Description-Content-Type
with --description-content-type where the default is text/x-rst

Alternate Solution

The alternative would be to not support Markdown, however, this would potentially decrease utility to end-users as Markdown project documentation is already commonplace.

Checkpoint workflow argument input

Allow positional argument input to the meson setup step in OZI-Project/checkpoint.

OZI does not support Download-URL header.

Issue Description

The Download-URL header in PKG-INFO is not provided by ozi-new.

Proposed Solution

Add a --download-url argument (single use).
Add a --ci-user argument (single use) defaulting to the result of git config --get user.name if --ci-provider=github.

Alternate Solution

Add a project.ci_user dependent on project.ci_provider.
Add a Download-URL output dependent on project.ci_provider.
Add dependency on GitPython

sdist builds disabled

Describe the bug

Building an sdist in Github CI fails with various permissions issues due to the way we construct wheels. We need to update PKG-INFO for meson dist based sdist build. I thought I would be able to fix this by merging PKG-INFO during the CI build but setuptools_scm still sees changes. I am currently considering that this might be due to the artifact folder not being included into .gitignore.

Now, personally I am fine with defaulting to only wheel releases being published to PyPI as they are built from the git tag/release distribution. Therefore, I am creating this issue for posterity as I am satisfied with the state of OZI being a wheel-only platform.