Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 12 commits
- 15 files changed
- 1 contributor
Commits on Jul 4, 2024
-
build: modernize by migrating to pyproject.toml with setuptools_scm
Prior to this commit, the project used `setup.cfg` and `versioneer` for version management. However, using versioneer is no longer considered best practice. In this commit, migrate the project to use `pyproject.toml` for build configuration, leveraging `setuptools_scm` for automatic versioning. This change aligns with [PEP 621][pep-621] standards and modernizes the project's packaging approach. The `pyproject.toml` file now contains essential metadata and configuration settings. This ensures that versioning is still managed dynamically based on SCM tags using `setuptools_scm`, whose [GitHub repo][setuptools-scm] "About" description states: > the blessed package to manage your versions by scm tags Specifically, the `setuptools_scm` package is [endorsed][pypa] by the Python Packaging Authority (PyPA), which is a working group that maintains many of the relevant projects in the Python packaging ecosystem, including setuptools. [pep-621]: https://peps.python.org/pep-0621/ [setuptools-scm]: https://github.com/pypa/setuptools_scm [pypa]: https://packaging.python.org/guides/single-sourcing-package-version/#using-setuptools-scm
Commits on Jul 5, 2024
-
-
-
ci: add CI workflow for automated testing
Prior to this commit, there was no automated CI workflow configured for the project, which meant that tests, linting, and code quality checks had to be run manually. This lack of automation could lead to inconsistencies and human errors. In this commit, add a new CI workflow is using GitHub Actions. The workflow includes: - Run tests on push and pull requests to the main branch. - Run tests on multiple Python versions (3.7, 3.8, 3.9, 3.10). - Cache dependencies to speed up the workflow. - Lint the code with flake8. - Check code formatting with black. - Run tests with pytest and collect coverage reports. - Upload coverage reports to Codecov.
-
ci: only run the publish job on a GitHub release event
Prior to this commit, an attempt was made to publish the built package for each "main" push or pull request. However, PyPI does not support dev snapshot versions since (originally posted by @dstufft [here][1]): > The `+something` namespace is explicitly disallowed on PyPI, because the > primary thing they are designed to solve is to give people modifying a library > a place to add their own versioning system on top of the upstream versioning, > without risking namespace collision (for instance, I might modify foo `5.7` and > change the version to `5.7+dstufft.fixedabug`. This lead to the errors like the following: ``` Uploading si_prefix-0.1.dev1+gb83616b-py3-none-any.whl WARNING Error during upload. Retry with the --verbose option for more details. ERROR HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/ The use of local versions in <Version('0.1.dev1+gb83616b')> is not allowed. See https://packaging.python.org/specifications/core-metadata for more information. ``` In this commit, configure the `publish` job to _only_ run on releases. This should prevent dev snapshot versions from being published. [1]: pypi/legacy#731 (comment)
-
-
-
-
-
-
style: convert module attr comment docs to docstrings
This is better supported by IDEs (e.g., vscode) and allows for a flake8 line length exception (i.e., `# noqa: E501`) to be applied.
-
Merge pull request #13 from cfobel/fix/build-add-python-3.12-compatib…
…ility fix(build): add python 3.12 compatibility
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v1.2.3...v1.3.0