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.
>> The metadata takes the form of a `dist-info` directory installed in
>> `%{python3_sitelib}` or `%{python3_sitearch}`, and contains
>> information that tools like
>> [`importlib.metadata`](https://docs.python.org/3/library/importlib.metadata.html)
>> use to introspect installed libraries.
>>
>> > XXX example %files with manual dist-info entry
>>
>> Note that some older tools instead put metadata in an `egg-info`
>> directory, or even a single file.
>> This won't happen if you use the `%pyproject_wheel` macro.
>> If your package uses a build system that generates an `egg-info`
>> directory or file, please contact Python SIG.
>>
>> > XXX We need a better solution before we go out of beta.
>>
>> As an exception, the Python standard library **MAY** ship without
>> this metadata.
>>
>> <snip>
>>
>>
>> ## PyPI parity
>>
>> Every Python package in Fedora **SHOULD** also be available on [the
>> Python Package Index](https://pypi.org) (PyPI).
>>
>> The command `pip install PROJECTNAME` **MUST** install the same
>> package (possibly in a different version), install nothing, or fail
>> with a reasonable error message.
>
>
> What should I imagine under "reasonable error message"?
One that explains the situation. Not a segfault.
I think it's fine to leave this to the packager.
Maybe I'm missing some context, but I'm lost. Are we proposing to add
new functionality to pip that somehow handles this? Or how could the
packager influence pip's error message?
>> 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.
In the meantime, I would at least list these as common bcond names, as
Fedora-wide guidelines might take a while.
>> A popular testing tool, and one which is well integrated in Fedora,
>> is `tox`. Upstream, it is commonly used to test against multiple
>> Python versions. In a Fedora package, BuildRequire test dependencies
>> (see *Test dependencies* below) and run `tox` with:
>>
>> ```
>> %tox
>> ```
>>
>> <snip>
>>
>>
>> ### Test dependencies
>>
>> One part of the Python packaging ecosystem that is still not
>> standardized is specifying test dependencies (and development
>> dependencies in general).
>>
>> The best practice to specify tests is using an extra (XXX link to
>> section above, which should be fleshed out) like `[test]` or
>> `[dev]`. In this case, upstream's instructions to install test
>> dependencies might look like `pip install -e.[test]`.
>>
>> Projects using `tox` usually specify test dependencies in a
>> `tox`-specific format: a
>> [requires](https://tox.readthedocs.io/en/latest/config.html#conf-requires)
>> key in the configuration.
>>
>> Both forms are handled by the `%pyproject_buildrequires` macro, see
>> below.
>>
>> If upstream does not use either form, list test dependencies as
>> manual *BuildRequires* in the `spec` file.
>
>
> Should these be manually listed as Fedora built RPM names
> (python3-testdep) or using the dist tag `python3dist(testdep)`?
Ideally, %{py3_dist pytest}.
Even more ideally, this is a temporary measure before the upstream
release :)
I've added it as an example.
Perfect!