So over the next few weeks I will be creating issues for enhancements I would like to get done before the Alpha release in January. I will also be reconstructing blastpipe with the ozi-new
tool as the slice demonstration test it originally was intended to be.
So I am very pleased with the current state of OZI. I am confident an Alpha can start before year end. To that end I will need to update blastpipe
to be created from the OZI publishing scripts, ozi-new
and ozi-fix
. It is likely that we will need to rethink the mechanics of integration into the OZI release process. Currently it gets very confused about the path if you run blastpipe
as a subproject. That is, it attempts to run from the toplevel project directory.
As of 13-Sept-2023 I have switched the main repository license to Apache-2.0 WITH LLVM-Exception.
This will reduce the burden of notice and attribution on projects published by OZI’s end users using the ozi-new
tool.
Over the past week I have been working on making the publishing script ozi-new
support PEP639’s potential changes to PyPA classifiers. Until the Python Packaging Authority accepts or rejects PEP639
we will warn users who select an ambiguous License classifier to clarify it with License-Expression and License-File keys. Currently these keys are slated for implementation in Metadata-Version 2.4.
Until then we are using a comment at the top of the PKG-INFO payload e.g.
.. OZI
Classifier: License-Expression :: [SPDX-License-Expression]
Classifier: License-File :: LICENSE.txt
The majority of the Pre-Alpha work remaining will be documentation related.
This is what will need to happen before working on an Alpha version for PyPI:
Satisfy the following Best Practices silver attestations:
The project website is reasonably done style and mobile support wise. I strived to match the style of our documentation subdomain. I have kept the minimal theme code block styling for now until I want to figure out styling. Back to working on the actual codebase…
This is the standard snippet I have been using:
[tool.coverage.report]
exclude_lines = [
"#\\s*(pragma|PRAGMA)[:\\s]?\\s*(no|NO)\\s*(cover|COVER)",
"#\\s*(pragma|PRAGMA)[:\\s]?\\s*(defer|DEFER)\\s*(to|TO)\\s*[a-zA-Z0-9_]*",
...
]
I am Eden Rose, the maintainer of the OZI project. I am a freelance developer. Code is a way I express myself. In the past I have fallen into the trap of only writing hobby projects. I enjoyed those very much but am wanting something less substantial but more community-focused. Python is the programming language I use the most. The Python community needs ways to reduce the packaging learning curve.
The OZI project focuses on packaging Python modules with Meson.
Let’s talk about about OZI in-the-large:
In many cases coverage reports will indicate blocks of code that writing a test for would amount to implementing a sanity check of the principal and reimplementing their test cases.
e.g. looping over simplicial types:
# pragma: defer to python