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:
>>> <snip>
>>>
>>> ### 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-insta...).
>>>
>>>
>>> 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).
<snip>
>>> If this is not the case, the packager **MUST** contact
upstream
>>> about this. The goal is to get the project name registered or
>>> blocked on PyPI, or to otherwise ensure the rule is followed.
>>>
>>> > XXX Note that project names that were in Fedora but not on PyPI
>>> when these guidelines were proposed are *blocked* as we discuss how
>>> they should be handled.
>>> > This prevents potential trolls, but also legitimate owners, from
>>> taking them.
>>>
>>> This is necessary to protect users, avoid confusion, and enable
>>> automation as Fedora and upstream ecosystems grow more integrated.
>>>
>>> As always, specific exceptions can be granted by FPC (XXX link
>>> exceptions rules).
>>>
>>> > XXX Write an automated check for this.
>>>
>>>
>>> <snip>
>>>
>>>
>>> ## 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/....
>>
>>
>>
>> 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.
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.
<snip>