Am 02.02.2023 11:50 schrieb BiT dev:
Yes, our changelog would work (if I hadn't forgotten to capture the newly discovered dependencies there BEFORE the release :-(
That isn't a big deal. ;) The workflow is something we need to train and we will become warm with. When we would have a second changelog then we will have two documents we need to maintain and with redundant information we need to kept sync.
I think we need to get a clear picture if and how pyproject.toml
Upcoming... This moves the entry up on my todo list. ;)
- maintains python-external dependencies (like eg. themes and icons or required cmd line tools like rsync) in a distro-independent (!) way (different pkg names), e.g.: Ubuntu: oxygen-icon-theme Arch: oxygen-icons
If the answer above question is YES: Could we end up then in doing the pkg maintenance half-way ourselves then (instead of letting downstreams do the work)?
You bring up some good question. I will do more research about it. I would answer partial YES. But keep in mind it is not our responsibility (as upstream) to take care of package names in distros. This is up to the distro maintainers. And I assume they have tools to handle that. For example when I need "pyfakefs" as a dependency a Debian maintainer today should be able to translate that into "python-pyfakefs" debian-package name. I'm not sure how they handle that but we don't have to care. But I will ask just for our knowledge. For external dependencies not related to Python I'm currently not aware of a pyproject-toml-related solution. I also doubt that the Python build system is related to that task. But I'll check out and suspect that we are not the first ones with that "problem". Maybe there is something like a MANIFEST or requirements file standard.
Also: My current understanding is (by flying over the PEP-specs for this) that pyproject.TOML is mainly meant for metadata and *build* dependencies while I have not directly seen a way to separately specify the *installation* dependencies (but I have not fully read the PEP-specs so far).
It is also independent from the build tools where are several exists in the python universe. See this real world example https://codeberg.org/buhtz/buhtzology/src/branch/develop/pyproject.toml Beginning on line 32 with "dependencies = [" you find 6 packages that could be named "install dependencies". They are installed/checked by default when you do python3 -m pip install buhtzology When you also want to make unittests and all the other stuff that is related to developers, contributors and maintainers you have to explicit specify this. python3 -m pip install buhtzology[dev] You see the "[dev]"? This an optional dependency named by myself and specified in line 41 in pyproject.toml. You can have as much as you like. Example here in section "Dependencies": https://godatadriven.com/blog/a-practical-guide-to-setuptools-and-pyproject-... As a short preview to my pyproject-toml-for-BIT-approach. The fact that we have two "components" (GUI and CLI) make it complex. My first approach works but is not a good solution from the viewpoint of distro maintainers. So I will implement another one. We can discuss this then in details later. I'll report back. Christian