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-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.
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/#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.
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!
_______________________________________________
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
