On 6/8/20 11:58 AM, Petr Viktorin wrote:
On 2020-06-05 16:12, Tomas Orsava wrote:
On 6/5/20 2:26 PM, Petr Viktorin wrote:
On 2020-06-05 11:51, Tomas Orsava wrote:
On 6/5/20 11:26 AM, Petr Viktorin wrote:
On 2020-06-03 21:49, Tomas Orsava wrote:
Hi,
I have left a few notes about the text itself as comments in the
document.
Comments about the subject matter are inlined below:
On 4/30/20 3:41 PM, Petr Viktorin wrote:
### Dist-info metadata
Each Python package **MUST** include *Package Distribution
Metadata* conforming to [PyPA
specifications](https://packaging.python.org/specifications/)
(specifically, [Recording installed
distributons](https://packaging.python.org/specifications/recording-installed-packages/)).
This applies to libraries (e.g. `python-requests`) as well as
tools (e.g. `ansible`).
> XXX what with splitting into subpackages? 1) dist-info always
installed, 2) dist-info installed trough a metapackage?
> * Ideally, do the split upstream
> * Consider package split between library & tool (see poetry,
fedpkg)
>
> e.g.
> When software is split into several subpackages, it is OK to
only ship metadata in one built RPM.
dist-info usually corresponds to an importable module, so let's
say that it SHOULD be in the same subpackage as the importable
module?
But if you split that module, which submodule does the dist-info
go to?
I'd leave it to the packager; all these cases are different.
That's why I suggested the SHOULD, because there will be
exceptions. But I think these guidelines might be read by people
who will not be actively aware of the relationship between
dist-info and a Python importable module, so I would add guidance
that these should be together if possible.
Please suggest the wording you'd like to see.
The one you have has the problem that there can be more importable
modules in one project. It doesn't give any guidance for what to do
if you split the project.
Of course, if you put importable module(s) in one subpackage and
documentation in another, the dist-info should be with the module(s).
I'm trying to read this guide through the eyes of someone starting
out with Fedora and/or Python, so I'd rather not assume people know
these details.
How about:
When software is split into several subpackages, it is OK to only
ship metadata in one built RPM. If the project contains an
importable module(s), the metadata SHOULD be included in the same
subpackage as the (main) importable module.
(First sentence already was in the text, I included it for context.)
I added it. I put the **SHOULD** sentence near the top of the section
to align to the organization of the document: rules first,
explanations/examples under them.
Looks good, thank you.
All in all, really nice document. Let me know if you could use more help
with it!
Tomas
## Tests
### Running tests
If a test suite exists, it **MUST** be run in the `%check`
section and/or in Fedora CI.
You **MAY** exclude specific failing tests.
You **MUST NOT** disable the entire testsuite or ignore the
result to solve a build failure.
As an exception, you **MAY** disable tests with an appropriate
`%if` conditional (e.g. bcond) when
[bootstrapping](https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping).
I would like to see either that the bcond SHOULD be named `tests`
(or possibly `check`), or if that's too strong, at least
recommend these two as common bcond names.
I agree, but it should be a Fedora-wide guideline.
True. Does anyone know if this is already in progress somewhere? I
remember it being talked about. Otherwise I guess the best way will
be for me to open a new thread about this.
Please do.
Here we go:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/443LZIX4XLZL6NMF3M7HAGHKPNA4TRYN/
>>
In the meantime, I would at least list these as common bcond names,
as Fedora-wide guidelines might take a while.
The Python guidelines will also take a while, and I'd like to avoid
giving different guidelines than what we come up with for Fedora.
Makes sense. I've added an "XXX" note to the text so we don't forget
to address this later.
Thanks!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
