borgmatic-collective/borgmatic
borgmatic-collective/borgmatic
10
65
Fork 26
Code Issues 42 Pull Requests 4 Actions Packages Releases 140 Activity

pyproject-transition #922

Merged
witten merged 7 commits from kaliko/borgmatic:pyproject-transition into main 2024-10-26 23:38:35 +00:00
Conversation 9 Commits 7 Files Changed 6 +1 -2
1 changed files with 1 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 9e29ce788f - Show all commits

3
scripts/release
View File

@ -33,8 +33,7 @@ git push github $version
# Build borgmatic and publish to pypi.
rm -fr dist
python3 setup.py bdist_wheel
python3 setup.py sdist
witten marked this conversation as resolved Outdated
witten commented 2024-10-22 16:45:30 +00:00
Outdated
Review
Copy Link

Something is missing from the result tarball. Here's what I'm seeing on my machine:

$ tar tfz dist/borgmatic-1.9.0.dev0.tar.gz
borgmatic-1.9.0.dev0/
borgmatic-1.9.0.dev0/AUTHORS
borgmatic-1.9.0.dev0/LICENSE
borgmatic-1.9.0.dev0/MANIFEST.in
borgmatic-1.9.0.dev0/PKG-INFO
borgmatic-1.9.0.dev0/README.md
borgmatic-1.9.0.dev0/borgmatic/
borgmatic-1.9.0.dev0/borgmatic/__init__.py
borgmatic-1.9.0.dev0/borgmatic/config/
borgmatic-1.9.0.dev0/borgmatic/config/schema.yaml
borgmatic-1.9.0.dev0/borgmatic/execute.py
borgmatic-1.9.0.dev0/borgmatic/logger.py
borgmatic-1.9.0.dev0/borgmatic/signals.py
borgmatic-1.9.0.dev0/borgmatic/verbosity.py
borgmatic-1.9.0.dev0/borgmatic.egg-info/
borgmatic-1.9.0.dev0/borgmatic.egg-info/PKG-INFO
borgmatic-1.9.0.dev0/borgmatic.egg-info/SOURCES.txt
borgmatic-1.9.0.dev0/borgmatic.egg-info/dependency_links.txt
borgmatic-1.9.0.dev0/borgmatic.egg-info/entry_points.txt
borgmatic-1.9.0.dev0/borgmatic.egg-info/requires.txt
borgmatic-1.9.0.dev0/borgmatic.egg-info/top_level.txt
borgmatic-1.9.0.dev0/pyproject.toml
borgmatic-1.9.0.dev0/sample/
borgmatic-1.9.0.dev0/sample/systemd/
borgmatic-1.9.0.dev0/sample/systemd/borgmatic-user.service
borgmatic-1.9.0.dev0/sample/systemd/borgmatic-user.timer
borgmatic-1.9.0.dev0/sample/systemd/borgmatic.service
borgmatic-1.9.0.dev0/sample/systemd/borgmatic.timer
borgmatic-1.9.0.dev0/setup.cfg

Notice how most of the source subdirectories are missing: borgmatic/actions/, borgmatic/borg/, etc.

Something is missing from the result tarball. Here's what I'm seeing on my machine: ``` $ tar tfz dist/borgmatic-1.9.0.dev0.tar.gz borgmatic-1.9.0.dev0/ borgmatic-1.9.0.dev0/AUTHORS borgmatic-1.9.0.dev0/LICENSE borgmatic-1.9.0.dev0/MANIFEST.in borgmatic-1.9.0.dev0/PKG-INFO borgmatic-1.9.0.dev0/README.md borgmatic-1.9.0.dev0/borgmatic/ borgmatic-1.9.0.dev0/borgmatic/__init__.py borgmatic-1.9.0.dev0/borgmatic/config/ borgmatic-1.9.0.dev0/borgmatic/config/schema.yaml borgmatic-1.9.0.dev0/borgmatic/execute.py borgmatic-1.9.0.dev0/borgmatic/logger.py borgmatic-1.9.0.dev0/borgmatic/signals.py borgmatic-1.9.0.dev0/borgmatic/verbosity.py borgmatic-1.9.0.dev0/borgmatic.egg-info/ borgmatic-1.9.0.dev0/borgmatic.egg-info/PKG-INFO borgmatic-1.9.0.dev0/borgmatic.egg-info/SOURCES.txt borgmatic-1.9.0.dev0/borgmatic.egg-info/dependency_links.txt borgmatic-1.9.0.dev0/borgmatic.egg-info/entry_points.txt borgmatic-1.9.0.dev0/borgmatic.egg-info/requires.txt borgmatic-1.9.0.dev0/borgmatic.egg-info/top_level.txt borgmatic-1.9.0.dev0/pyproject.toml borgmatic-1.9.0.dev0/sample/ borgmatic-1.9.0.dev0/sample/systemd/ borgmatic-1.9.0.dev0/sample/systemd/borgmatic-user.service borgmatic-1.9.0.dev0/sample/systemd/borgmatic-user.timer borgmatic-1.9.0.dev0/sample/systemd/borgmatic.service borgmatic-1.9.0.dev0/sample/systemd/borgmatic.timer borgmatic-1.9.0.dev0/setup.cfg ``` Notice how most of the source subdirectories are missing: `borgmatic/actions/`, `borgmatic/borg/`, etc.
kaliko commented 2024-10-22 19:44:53 +00:00
Outdated
Review
Copy Link

Package discovery was broken indeed and somehow my test failed to raise the issue (some leftovers interfered I guess). Anyway I fixed this in 601e393ec7.

I'm hoping to have more time next week to work on your comments,
Thanks for the review.

Package discovery was broken indeed and somehow my test failed to raise the issue (some leftovers interfered I guess). Anyway I fixed this in 601e393ec7. I'm hoping to have more time next week to work on your comments, Thanks for the review.
witten commented 2024-10-22 22:37:05 +00:00
Outdated
Review
Copy Link

Cool, yeah, the tarball contents look much better now!

Cool, yeah, the tarball contents look much better now!
python3 -m build
witten marked this conversation as resolved
witten commented 2024-10-22 16:25:47 +00:00
Review
Copy Link

When I try this inside a Python 3 virtualenv, the command doesn't appear to work:

$ python3 -m build
/home/witten/Downloads/borgmatic/.tox/py312/bin/python3: No module named build

Looks like it might need to be added to test_requirements.txt? And/or to [build-system] in pyproject.toml?

When I try this inside a Python 3 virtualenv, the command doesn't appear to work: ``` $ python3 -m build /home/witten/Downloads/borgmatic/.tox/py312/bin/python3: No module named build ``` Looks like [it might need to be added]( https://build.pypa.io/en/stable/installation.html) to `test_requirements.txt`? And/or to `[build-system]` in `pyproject.toml`?
kaliko commented 2024-10-26 09:12:52 +00:00
Review
Copy Link

I believe there are two different issues here. One regarding tox and another one concerning the release script.

My understanding of recent python packaging is that build module is only a build frontend supporting pyproject.toml to call the build-system (cf. doc here).

I believe we don't' need to tell tox to use it, and apparently tox can build the package without it, probably using plain pip (an alternative build frontend ).

Then there is no need to add build module to test_requirements.txt IMHO.

But I fixed scripts/release to use it instead setup.py.
Then I guess we should add build dependency somewhere in the release process.
Could be test_requirements.txt if you run the script within a tox venv, but I believe it's better to release from a pristine environment to avoid side effects of pre-populated venv with tons of deps for test/coverage/lint/etc….

But this is something I let you decide, I don't know how you release borgmatic.

I believe there are two different issues here. One regarding **tox** and another one concerning the **release script**. My understanding of recent python packaging is that ``build`` module is only a build frontend supporting ``pyproject.toml`` to call the ``build-system`` (cf. [doc here](https://packaging.python.org/en/latest/tutorials/packaging-projects/#choosing-a-build-backend)). I believe we don't' need to tell tox to use it, and apparently tox can build the package without it, probably using plain ``pip`` (an alternative build frontend ). Then there is no need to add ``build`` module to ``test_requirements.txt`` IMHO. But I fixed ``scripts/release`` to use it instead ``setup.py``. Then I guess we should add ``build`` dependency somewhere in the release process. Could be ``test_requirements.txt`` if you run the script within a tox venv, but I believe it's better to release from a pristine environment to avoid side effects of pre-populated venv with tons of deps for test/coverage/lint/etc…. But this is something I let you decide, I don't know how you release borgmatic.
witten commented 2024-10-26 15:46:18 +00:00
Review
Copy Link

Thanks for the explanation. I typically release borgmatic manually by running scripts/release on my machine (not from a virtualenv), although I'm open to changing the process if it would help. But if the release script is the only place that requires a build dependency, I'm fine just manually installing it on my machine for now. And then if/when the release script moves to, say, CI, that automated process can install build accordingly.

Thanks for the explanation. I typically release borgmatic manually by running `scripts/release` on my machine (not from a virtualenv), although I'm open to changing the process if it would help. But if the release script is the only place that requires a `build` dependency, I'm fine just manually installing it on my machine for now. And then if/when the release script moves to, say, CI, that automated process can install `build` accordingly.
twine upload -r pypi --username __token__ dist/borgmatic-*.tar.gz
twine upload -r pypi --username __token__ dist/borgmatic-*-py3-none-any.whl