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:
>>>>>> <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).
>
>
> 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
<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.
>
> Here we go:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> >>
>>> 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!