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.
> 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.
> 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.
> 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.