python-devel October 2020

python-devel@lists.fedoraproject.org

8 participants
9 discussions

Draft of New Python Packaging Guidelines
by Petr Viktorin 15 Jun '21

15 Jun '21

Hello! Below is a draft of new Packaging Guidelines! It's full of unfinished areas (marked with XXX), but it's ready for scrutiny. A possibly updated version is on https://hackmd.io/XzJe-sHUQvWK7cSrEH_aKg?view Generally, for rules marked **SHOULD** we know of cases where they should be broken; for things marked **MUST** we don't. We have tried to only take the Good Existing Things™ (macros, practices) and revise the rest without thinking about the past much. Some used technology is unfortunately not compatible with current EPELs, but we have considered Fedora 31+. Using the current Python guidelines will still be an option for people who target EPEL 6/7/8. The main controversial idea (of many) is synchronizing Fedora's names (a.k.a. `python3dist(...)`, a.k.a. `name` in `setup.py`) with the Python Package Index (PyPI, pypi.org) which has by now become the de-facto canonical namespace for freely redistributable Python packages. We believe that this will help both Fedora and the greater Python ecosystem, but there will definitely be some growing pains. Most of Fedora Python packages already are on PyPI, but more than 250 are missing. There is software developed within Fedora (e.g. pagure, fedpkg, rust2rpm); projects that aren't primarily Python packages (e.g. perf, ceph, xen, setroubleshoot, iotop); and others. A full list is attached. The names have been temporarily blocked on PyPI to keep trolls from taking them while this is discussed. Over at the Python Discourse we are discussing how to properly handle these; once that discussion is settled they should be unblocked: https://discuss.python.org/t/pypi-as-a-project-repository-vs-name-registry-… Another general idea is that package metadata should be kept upstream; the spec file should duplicate as little of it as possible. Any adjustments should be done with upstreamable patches. The draft lives on hackmd.io, which we found easy to collaborate with. If you have an account there, we can add you. If you'd like to collaborate some other way, let us know. Petr and Miro ----------------------- Current draft for inline comments: > [IMPORTANT] > This is a DRAFT; it is not in effect yet. # Python Packaging Guidelines (draft) > [IMPORTANT] > This is a *beta* version of the Python Packaging Guidelines and the associated RPM macros. > Packagers that opt in to following this version **MUST** be prepared to change their packages frequently when the guidelines or macros are updated. > These packagers **SHOULD** join [Python SIG mailing list](https://lists.fedoraproject.org/archives/list/python-devel@lists.fedo… and monitor/start conversations there. These Guidelines represent a major rewrite and paradigm shift, and not all packages are updated to reflect this. Older guidelines are still being kept up to date, and existing packages **MAY** use them instead of this document: * 201x-era Python packaging guidelines (for packages that use e.g. `%py3_install` or `setup.py install`) * Python 2 appendix (for e.g. `%py2_install`) (requires FESCo exception) > [NOTE] > These guidelines only support Fedora 31+. For older releases (such as in EPEL 8), consult the older guidelines (XXX link). The two "Distro-wide guidelines" below apply to all software in Fedora that uses Python at build- or run-time. These rest of the Guidelines apply to packages that ship code that *can* be imported in Python. Specifically, that is all packages that install files under `/usr/lib*/python*/`. Except for the two "Distro-wide guidelines", these Guidelines do not apply to simple one-file scripts or utilities, especially if these are included with software not written in Python. However, if an application (e.g. CLI tool, script or GUI app) needs a more complex Python library, the library **SHOULD** be packaged as an importable library under these guidelines. A major goal for Python packaging in Fedora is to *harmonize with the wider Python ecosystem*, that is, the [Python Packaging Authority](https://pypa.io) (PyPA) standards and the [Python Package Index](https://pypi.org) (PyPI). Packagers **SHOULD** be prepared to get involved with upstream projects to establish best practices as outlined here. We wish to improve both Fedora and the wider Python ecosystem. > [NOTE] > Fedora's Python SIG not only develops these guidelines, but it's also involved in PyPA standards and Python packaging best practices. Check out [the wiki](https://fedoraproject.org/wiki/SIGs/Python) or [mailing list](https://lists.fedoraproject.org/archives/list/python-devel@lists.fedo… if you need help or wish to help out. ## Distro-wide guidelines ### BuildRequire python3-devel **Every** package that uses Python (at runtime and/or build time), and/or installs Python modules **MUST** explicitly include `BuildRequires: python3-devel` in its `.spec` file, even if Python is not actually invoked during build time. If the package uses an alternate Python interpreter instead of `python3` (e.g. `pypy`, `jython`, `python27`), it **MAY** instead require the coresponding `*-devel` package. The `*-devel` package brings in relevant RPM macros. It may also enable automated or manual checks: for example, Python maintainers use this requirement to list packages that use Python in some way and might be affected by planned changes. ### Mandatory macros The following macros **MUST** be used where applicable. The expansions in parentheses are provided only as reference/examples. The macros are defined for you in all supported Fedora and EPEL versions. * `%{python3}` (`/usr/bin/python3`) The Python interpreter. For example, this macro should be used for invoking Python from a `spec` file script, passed to `configure` scripts to select a Python executable, or used as `%{python3} -m pytest` to run a Python-based tool. > XXX: Use shebang opts for shebang; document pathfix macro. Document cases where you don't want this. * `%{python3_version}` (e.g. `3.9`) Version of the Python interpreter. * `%{python3_version_nodots}` (e.g. `39`) Version of the Python interpreter without the dot. * `%{python3_sitelib}` (e.g. `/usr/lib/python3.9/site-packages`) Where pure-Python modules are installed. * `%{python3_sitearch}` (e.g. `/usr/lib64/python3.9/site-packages`) Where Python3 extension modules (native code, e.g. compiled from C) are installed. The rest of this document uses these macros, along with `%{_bindir}` (`/usr/bin/`), instead of the raw path names. ## Python implementation support Fedora primarily targets *CPython*, the reference implementation of the Python language. We generally use “Python” to mean CPython. Alternate implementations like `pypy` are available, but currently lack comprehensive tooling and guidelines. When targetting these, there are no hard rules (except the general Fedora packaging guidelines). But please try to abide by the *spirit* of these guidelines. When in doubt, consider consulting the Python SIG. ## Python version support Fedora packages **MUST NOT** depend on other versions of the CPython interpreter than the current `python3`. In Fedora, Python libraries are packaged for a single version of Python, called `python3`. For example, in Fedora 32, `python3` is Python 3.8. In the past, there were multiple Python stacks, e.g. `python3.7` and `python2.7`, installable together on the same machine. That is also the case in some projects that build *on top* of Fedora, like RHEL, EPEL and CentOS. Fedora might re-introduce parallell-installable stacks in the future (for example if a switch to a new Python version needs a transition period, or if enough interested maintainers somehow appear). > XXX dots in package names! Fedora does include alternate interpreter versions, e.g. `python2.7` or `python3.5`, but these are meant only for developers that need to test upstream code. Bug and security fixes for these interpreters only cover this use case. Packages such as `pip` or `tox`, which enable setting up isolated environments and installing third-party packages into them, **MAY**, as an exception to the rule above, use these interpreters as long as this is coordinated with the maintainers of the relevant Python interpreter. ## BuildRequire pyproject-rpm-macros While these guidelines are in Beta, each Python package **MUST** have `BuildRequires: pyproject-rpm-macros` to access the beta macros. (When we go out of Beta, listing the dependency won't be necessary: we'll make `python3-devel` require it.) ## Naming Python packages have several different names, which should be kept in sync but will sometimes differ for historical or practical reasons. They are: * the Fedora *source package name* (or *component name*, `%{name}`), * the Fedora *built RPM name*, * the *project name* used on *PyPI* or by *pip*, and * the *importable module name* used in Python (a single package may have multiple importable modules). Some examples (both good and worse): | Fedora component | Built RPM | Project name | Importable module | | ----------------- | ------------------ | -------------- | -------------------- | | `python-requests` | `python3-requests` | `requests` | `requests` | | `PyYAML` | `python3-pyyaml` | `pyyaml` | `yaml` | | `python-ldap` | `python3-ldap` | `python-ldap` | `ldap`, `ldif`, etc. | | `python-pillow` | `python3-pillow` | `pillow` | `PIL` | Elsewhere in this text, the metavariables `SRPMNAME`, `RPMNAME`, `PROJECTNAME`, `MODNAME` refer to these names, respectively. ### Canonical project name Most of these names are case-sensitive machine-friendly identifiers, but the *project name* has human-friendly semantics: it is case-insensitive and treats some sets of characters (like `._-`) specially. For automated use, it needs to be [normalized](https://www.python.org/dev/peps/pep-0503/#normalized-names) to a canonical format used by Python tools and services such as setuptools, pip and PyPI. The `%{py_dist_name}` macro implements this normalization. Elsewhere in this text, the metavariable `DISTNAME` refers to the canonical form of the project name. > XXX > ```spec > # XXX specfile > %py_set_name Django > -> %distname django > -> %pojectname Django > ``` > > XXX rewrite: It is customary to define the macro `%{distname}` as the canonical project name and use it throughout the `spec` file. Some helper macros use `%{distname}` for this purpose by default. > > XXX in some places, the "original project name" must be used -- e.g. `%pypi_source` and `%autosetup` need `Django`, not `django`. > XXX The following sections should supersede the [Python section on the Naming guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Namin…. ### Library naming A built (i.e. non-SRPM) package for a *Python library* **MUST** be named with the `python3-` prefix. A source package containing primarily a *Python library* **MUST** be named with the prefix `python-`. The Fedora package's name **SHOULD** contain the *canonical project name*. If possible, the project name **SHOULD** be the same as the name of the main importable module, with underscores (`_`) replaced by dashes (`-`). A *Python library* is a package meant to be imported in Python, such as with `import requests`. Tools like *Ansible* or *IDLE*, whose code is importable but not primarily meant to be imported, are not considered libraries in this sense, so this section does not apply for them. (See the [general Libraries and Applications guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/#_lib… for details.) If the importable module name and the project name do not match, users frequently end up confused. In this case, packagers *should* ensure that upstream is aware of the problem and (especially for new packages where renaming is feasible) strive to get the package renamed. The Python SIG is available for assistance. The Fedora package name should be formed by taking the *project name* and prepending `python-` if it does not already start with `python-`. This may leads to conflicts (e.g. between [bugzilla](https://pypi.org/project/bugzilla/) and [python-bugzilla](https://pypi.org/project/python-bugzilla/)) In that case, ensure upstream is aware of the potentially confusing naming and apply best judgment. ### Application naming Packages that primarily provide executables **SHOULD** be named according to the general Fedora guidelines (e.g. `ansible`). Consider adding a virtual provide according to Library naming above (e.g. `python3-PROJECTNAME`), if it would help users find the package. ## Files to include ### Source files and bytecode cache Packages **MUST** include the source file (`*.py`) **AND** the bytecode cache (`*.pyc`) for each pure-Python module. The cache files are found in a `__pycache__` directory and have an interpreter-dependent suffix like `.cpython-39.pyc`. The cache is not necessary to run the software, but if it is not found, Python will try to create it. If this succeeds, the file is not tracked by RPM and it will linger on the system after uninstallation. If it does not succeed, users can get spurious SELinux AVC denials in the logs. Normally, byte compilation (generating the cache files) is done for you by the `brp-python-bytecompile` script (XXX link to BRP guidelines), which runs automatically after the `%install` section of the spec file has been processed. It byte compiles any `.py` files that it finds in `%{python3_sitelib}` or `%{python3_sitearch}`. You must include these files of your package (i.e. in the `%files` section). If the code is in a subdirectory (importable package), include the entire directory: ``` %files %{python3_sitelib}/foo/ ``` Adding the trailing slash is best practice for directories. However, this cannot be used for top-level scripts (those directly in e.g. `%{python3_sitelib}`), because both `%{python3_sitelib}` and `%{python3_sitelib}/__pycache__/` are owned by Python itself. Here, the `%pycached` macro can help. It expands to the given `*.py` source file and its corresponding cache file(s). For example: ``` %files %pycached %{python3_sitelib}/foo.py ``` expands roughly to: ``` %files %{python3_sitelib}/foo.py %{python3_sitelib}/__pycache__/foo.cpython-3X{,.opt-?}.pyc ``` #### Manual byte compilation If you need to bytecompile stuff outside of `%{python3_sitelib}`/`%{python3_sitearch}`, use the `%py_byte_compile` macro. For more details on `%py_byte_compile` and on the internals of bytecode compilation, please see the [appendix](https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_…. > XXX: Copy the section from appendix here ### 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-install…) 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. 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. ### Explicit lists Packagers **SHOULD NOT** simply glob everything under a shared directory. In particular, the following **SHOULD NOT** be used: * `%{python3_sitelib}/*` * `%{python3_sitearch}/*` * `%{python_sitelib}/*` * `%{python_sitearch}/*` * `%{_bindir}/*` * `%pyproject_save_files *` * `%pyproject_save_files +bindir` This rule serves as a check against common mistakes which are otherwise hard to detect. It does limit some possibilities for automation. The most common mistake this rule prevents is installing a test suite system-wide as an importable module named `test`, which would then conflict with other such packages. ## 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. 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. ## Provides and requirements ### Provides for importable modules For any module intended to be used in Python 3 with `import MODNAME`, the package that includes it **SHOULD** provide `python3-MODNAME`, with underscores (`_`) replaced by dashes (`-`). This is of course always the case if the package is named `python3-MODNAME`. If the subpackage has some other name, then add `%py_provides python3-MODNAME` explicitly. See the following section to learn about `%py_provides`. ### Automatic unversioned provides For any `FOO`, a package that provides `python3-FOO` **SHOULD** use `%py_provides` or an automatic generator to also provide `python-FOO`. The provide **SHOULD NOT** be added manually: if the generator or macro is not used, the provide shall not be added at all. On Fedora 33+, this is done automatically for package names by a generator. The generator can be disabled by undefining `%__pythonname_provides`. The following macro invocation will provide both `python3-FOO` and `python-FOO`: %py_provides python3-FOO > XXX: finalize `%py_provides` Using the generator or macro is important, because the specific form of the provide may change in the future. ### Machine-readable provides Every Python package **MUST** provide `python3dist(DISTNAME)` **and** `python3.Xdist(DISTNAME)`, where `X` is the minor version of the interpreter and `DISTNAME` is the *canonical project name* corresponding to the *dist-info metadata*, for example `python3.9dist(requests)`. (XXX: add links to previous sections) This is generated automatically from the dist-info metadata. The provide **SHOULD NOT** be added manually: if the generator fails to add it, the metadata **MUST** be fixed. If necessary, the automatic generator can be disabled by undefining `%__pythondist_provides`. These *Provides* are used for automatically generated *Requires*. ### Dependencies As mentioned above, each Python package **MUST** explicitly BuildRequire `python3-devel`. Packages **MUST NOT** have dependencies (either build-time or runtime) with the unversioned prefix `python-` if the corresponding `python3-` dependency can be used instead. Packages **SHOULD NOT** have explicit dependencies (either build-time or runtime) with a minor-version prefix such as `python3.8-` or `python3.8dist(`. Such dependencies **SHOULD** instead be automatically generated or a macro should be used to get the version. Packages **SHOULD NOT** have an explicit runtime dependency on `python3`. Instead of depending on `python3`, packges have an automatic dependency on `python(abi) = 3.X` when they install files to `%{python3_sitelib}` or `%{python3_sitearch}`, or they have an automatic dependency on `/usr/bin/python3` if they have executable Python scripts, or they have an automatic dependency on `libpython3.X.so.1.0()` if they embed Python. These rules help ensure a smooth upgrade path when `python3` is updated in new versions of Fedora. ### Automatically generated dependencies Packages **MUST** use the automatic Python run-time dependency generator. Packages **SHOULD** use the opt-in build-dependency generator if possible. Any necessary changes **MUST** be done by patches or modifying the source (e.g. with `sed`), rather than disabling the generator. The resulting change **SHOULD** be offered to upstream. As an exception, [filtering](https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoPr… **MAY** be used for temporary workarounds and bootstrapping. Dependencies covered by the generators **SHOULD NOT** be repeated in the `.spec` file. (For example, if the generator finds a `requests` dependency, then `Requires: python3-requests` is redundant.) The automatically generated requirements are in the form `python3.Xdist(DISTNAME)`, potentially augmented with version requirements or combined together with [rich dependencies](https://rpm.org/user_doc/boolean_dependencies.html). Note that the generators only cover Python packages. Other dependencies, often C libraries like `openssl-devel`, must be specified in the `.spec` file manually. > XXX When implemented, this goes here: Alternatively, upstream Python packages may list non-Python dependencies in the `[tool.fedora.requires]`/`[tool.fedora.buildrequires]` section of `pyproject.toml`. This is non-standard and only recommended for Fedora-related packages. Where the requirements are specified in the source depends on each project's build system and preferences. Common locations are `pyproject.toml`, `setup.py`, `setup.cfg`, `config.toml`. #### Run-time dependency generator The automatic runtime dependency generator uses package metadata (as recorded in installed `*.dist-info` directories) to determine what the package depends on. In an emergency, you can opt-out from running the requires generator by adding `%{?python_disable_dependency_generator}` to the package (usually, just before the main package’s `%description`). #### Build-time dependency generator The opt-in (but strongly recommended) build-time dependency generator gathers information from [`pyproject.toml` build-system information](https://www.python.org/dev/peps/pep-0517/#source-trees) (with fallback to `setuptools`) plus a standardized [build-system hook](https://www.python.org/dev/peps/pep-0517/#get-requires-for-build-whee… to gather further requirements. See `%pyproject_buildrequires` (XXX link) for more details. ### Test dependencies See the *Tests* section. (XXX link.) ### Extras > XXX No story here so far. > XXX Note: [python-django-storages](https://src.fedoraproject.org/rpms/python-django-st…, `drf-yasg` etc. do `%python_provide python3-%{srcname}+%{distname}` and `python3dist(%{srcname}/%{extraname})` XXX `python3dist(%{srcname}[%{extraname}])` ## Interpreter invocation ### Shebangs Shebangs lines to invoke Python **SHOULD** be `#!%{python3} -%{py3_shebang_flags}` and it **MAY** include extra flags. > XXX define py3_shebang_flags If the default flags from `%{py3_shebang_flags}` are not desirable, packages **SHOULD** explicitly redefine the macro to remove them. Using `#!%{python3}` (`#!/usr/bin/python3`) rather than e.g. `#!/usr/bin/env python` ensures that the system-wide Python interpreter is used to run the code, even if the user modifies `$PATH` (e.g. by activating a virtual environment). By default, `-%{py3_shebang_flags}` expands to `-s`, which means *don't add user site directory to `sys.path`*. That ensures user-installed Python packages (e.g. by `pip install --user`) don't interfere with the RPM installed software. Sometimes, `pip`-installed content is desirable, such as with plugins. Redefining `%{py3_shebang_flags}` to not include `s`, rather than not using the macro at all, ensures that existing or future automation won't add the flag. The `%pyproject_install` macro automatically changes all Python shebangs in `%{buildroot}%{_bindir}/*` to use `%{python3}` and add `%{py3_shebang_flags}` to the existing flags. If you're not using the macro or you need to change a shebang in a different directory, you can use the `pathfix.py` command as follows: ``` pathfix.py -n -p -k -i %{python3} -a %{py3_shebang_flags} SCRIPTNAME … ``` > XXX Ouch! Macroize this? Hell yes! > > `%py3_shebang_fix <paths>` -- also rename `%{py3_shebang_flags}` (doesn't include dash) > > can be used in `%prep` or `%install` where: * `-n` disables ceating backups * `-p` preserves timestamps * `-k` keeps existing flags * `-i` specifies the new interpreter ### Invokable Python modules Every executable `TOOL` for which the current version of Python matters **SHOULD** also be invokable by `python3 -m TOOL`. If the software doesn't provide this functionality, packagers **SHOULD** ask the upstream to add it. This applies to tools that modify the current Python environment (like installing or querying packages), use Python for configuration, or use Python to run plugins. It does not apply to tools like GIMP or Bash which support plugins in multiple languages and/or have other means to specify the interpreter. For example, `pip` can be invoked as `python3 -m pip`. This allows users to accurately specify the Python version used to run the software. This convention works across different environments that might not always set `$PATH` or install scripts consistently. ## Using Cython Tightening the general Fedora policy, packages **MUST NOT** use files pre-generated by Cython. These **MUST** be deleted in `%prep` and regenerated during the build. As an exception, these sources **MAY** be used temporarily to prevent build time circular dependencies by following the [bootstrapping](https://docs.fedoraproject.org/en-US/packaging-guidelines/#b… guidelines. Generated files (the ones that must be deleted) have a generic `.c` or `.cpp` extension. Cython source files (which should stay) usually have the `.pyx` or `.pxd` extension. Cython is a popular tool for writing extension modules for Python. If compiles a Python-like language to C, which is then fed to the C compiler. Historically, Cython was hard to use upstream as a build-time dependency. Many projects include pre-generated C files in source distribution to avoid users from needing to install the tool. Cython uses CPython's fast-changing internal API for performance reasons. For a new release of Python, Cython generally needs to be updated and the C files regenerated. In Fedora, this is frequently needed before upstreams release re-generated sources (e.g. for Alpha versins of Python). Since we do not have a problem with build-time dependencies, we always want to run the Cython step. > XXX example spec snippet ## 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/#b…. 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 ``` This sets up the environment (`$PATH`, `$PYTHONPATH`, `$TOX_TESTENV_PASSENV`) and instructs `tox` to use the current environment rather than create new ones. For more options, see *Build macros* (XXX link to section). When upstream doesn't use `tox`, the tests need to be run directly depending on upstream choice of a test runner. A popular runner is `pytest`, which can be run against the package to be installed using: ``` export PATH=%{buildroot}%{_bindir} export PYTHONPATH=%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} /usr/bin/pytest # XXX `%{python} -m pytest` doesn't work :( -- sees PWD ``` > XXX Do we want a macro for that? We do, because not all projects have tox. > > Define %__pytest or %_pytest %pytest_command - /usr/bin/pytest > > Define %pytest (see above snippet) (not parametric) Use positional arguments to specify test directory, and `-k` to select tests (e.g. `-k "not network"` may deselect all network-related tests). ### 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. ### Linters In `%check`, packages **SHOULD NOT** run “linters”: code style checkers, test coverage checkers and other tools that check code quality rather than functionality. Tools like `black`, `pylint`, `flake8`, or `mypy` are often “opinionated” and their “opinions” change frequently enough that they are nuisance in Fedora, where the linter is not pinned to an exact version. Furthermore, some of these tools take a long time to adapt to new Python versions, preventing early testing with Aplha and Beta releases of Python. And they are just not needed: wrongly formatted code is not important enough for the Fedora packager to bug the upstream about it. Making such an issue break a package build is entirely unreasonable. Linters *do* make sense in upstream CI. But not in Fedora. If a linter is used, disable it and remove the dependency on it. If that is not easy, talk to upstream about making it easy (for example with a configuration option or a separate `tox` environment). For packages that contain such linters, use them at runtime or extend them, you will usually need to run the linter in `%check`. Run it to test functionality, not code quality of the packaged software. ## Source files from PyPI Packages **MAY** use sources from PyPI. However, packages **SHOULD NOT** use an archive that omits test suites, licences and/or documentation present in other source archives. For example, as of this writing `pip` provides a [source tarball (“sdist”)](https://pypi.org/project/pip/#files) which omits the relatively large `tests` and `docs` directories present in [the source on GitHub](https://github.com/pypa/pip). In this case, the tarball from GitHub should be used (XXX link to source URL guidelines). When using sources from PyPI, you can use the `%pypi_source` macro to generate the proper URL. See the *Macro reference* (XXX link directly to macro) for details. ## Sample spec file The following is a viable spec file for a hypothetical Python library called `pello` that follows packaging best practices. > XXX *Need to get `Pello` uploaded as real example and on GH under fedora-python. ``` %py_set_name Pello Name: python-%{distname} Version: 1.2.3 Release: 1%{?dist} Summary: Example Python library License: MIT URL: https://github.com/fedora-python/Pello Source0: %{pypi_source} BuildArch: noarch BuildRequires: python3-devel BuildRequires: pyproject-rpm-macros %global _description %{expand: A python module which provides a convenient example. This description provides some details.} %description %_description %package -n python3-%{distname} Summary: %{summary} %description -n python3-%{distname} %_description %prep %autosetup -p1 -n %{projectname}-%{version} %generate_buildrequires %pyproject_buildrequires -t %build %pyproject_wheel %install %pyproject_install # Here, "pello" is the name of the importable module. # You may use %%{distname} here if it's the same. %pyproject_save_files pello %check %tox # Note that there is no %%files section for # the unversioned python module, python-%%{distname} %files -n python3-%{distname} -f %{pyproject_files} %doc README.md %license LICENSE %{_bindir}/pello-greeting ``` ## Macro Reference See the *Mandatory macros* section above. (XXX link to section)  * `%{python3}` (`/usr/bin/python3`) * `%{python3_version}` (e.g. `3.9`) * `%{python3_version_nodots}` (e.g. `39`) * `%{python3_sitelib}` (e.g. `/usr/lib/python3.9/site-packages`) * `%{python3_sitearch}` (e.g. `/usr/lib64/python3.9/site-packages`) ### Name macros * `%py_set_name PROJECTNAME` (e.g. `%py_set_name Django`) Sets `%{projectname}` to the given name, and `%{distname}` to the canonical version of it. These macros can then be used throughout the `spec` file. See *Naming* for details and *Sample spec file* for examples. (XXX link to sections) * `%{projectname}` (e.g. `Django`) Set by `%py_set_name` to the *project name* of the software. * `%{distname}` (e.g. `django`) Set by `%py_set_name` to the *canonical project name* of the software. ### Shebang macro * `%{py3_shebang_flags}` (`s`) Flags for `%{python3}` to use in shebangs. Redefine this macro to use a different set of flags. See *Shebangs* [XXX link section] for details. ### Convenience macros * `%{pypi_source [PROJECTNAME [VERSION [EXT]]]}` (e.g. `https://.../Django-3.0.5.tar.gz`) Evaluates to the appropriate URL for source archive hosted on PyPI. Accepts up to three optional arguments: 1. The name of the PyPI project. Defaults to `%srcname` if defined, or to `%pypi_name` if defined, or to `%name` (the package name). [XXX default to `%projectname`] 2. The version of the PyPI project. Defaults to `%version` (the package version). 3. The file extension to use. Defaults to `tar.gz`. In most cases it is not necessary to specify any arguments. * `%{python3_platform}` (e.g. `linux-x86_64`) The platform name. Used in some Python build systems. ### Build macros These macros are most useful for packaging Python projects that use the `pyproject.toml` file defined in [PEP 518](https://www.python.org/dev/peps/pep-0518/) and [PEP 517](https://www.python.org/dev/peps/pep-0517/), which specifies the package's build dependencies (including the build system, such as setuptools, flit or poetry). If `pyproject.toml` is not found, the macros automatically fall backs to using `setuptools` with configuration in `setup.cfg`/`setup.py`. A full tutorial and discussion for the macros is available in the macros' [README](https://src.fedoraproject.org/rpms/pyproject-rpm-macros/). * `%pyproject_wheel` Build the package. Commonly, this is the only macro needed in the `%build` section. This macro needs BuildRequires generated by `%pyproject_buildrequires`. * `%pyproject_install` Install the package built by `%pyproject_wheel`. This macro needs BuildRequires generated by `%pyproject_buildrequires`. * `%pyproject_buildrequires` Generate BuildRequires for the package. Used in the `%generate_buildrequires` section of the `spec` file. The macro has these options: * `-r`: Include build-time requirements (commonly needed for `%check`). * `-x EXTRA`: Include dependencies given by the given *extra* (XXX link). [XXX Multiple comma separated values cannot be given yet.] * `-t`: Include dependencies for the default *tox* environment. Implies `-r`. * `-e ENV`: Include dependencies for the given *tox* environment, and save the `ENV` name as `%{toxenv}`. Implies `-r`. Multiple comma separated values can be given, for example: %pyproject_buildrequires -e %{toxenv}-unit,%{toxenv}-integration * `%pyproject_save_files MODNAME …` Generate a list of files corresponding to the given importable modules, and save it as `%{pyproject_files}`. Note that README and licence files are not included. Also, while the macro allows including executable files (using the `+bindir` flag), this feature **MUST NOT** be used in Fedora. The `MODNAME` may be a glob pattern, which should be specific to your package. As mentioned in the *Explicit lists* section, expressions like `%pyproject_save_files *` are not acceptable. * `%{pyproject_files}` Path of the file written by `%pyproject_save_files`, to be used as: %files -n python3-%{distname} -f %{pyproject_files} * `%tox` Run tests using `tox`. A different environment may be specified with `-e`, for example: ``` %check %tox %if %{with integration_test} %tox -e %{toxenv}-integration %endif ``` Flags for the `tox` command can be specified after `--`: %tox -- --parallel 0 Additional arguments for the test runner may be specified after another `--`: %tox -- --parallel 0 -- --verbose tests/* * `%{toxenv}` The *tox* environment used by the `%tox` macro. Can be overridden manually or with `%pyproject_buildrequires -t ENV`. * `%{default_toxenv}` (e.g. `py39`) The system-wide default value of `%{toxenv}`. ### Manual Generation The following macros are available for cases where automatic generation is turned off. They can also be useful for handling files in non-standard locations where the generators don't look. * `%pycached MODNAME.py` Given a Python file, lists the file and the files with its bytecode cache. See *Source files and bytecode cache* for more information. * `%{py_provides python3-MODNAME}` > XXX See *The `%python_provide` macro* for more details. * `%{py_byte_compile INTERPRETER PATH}` > XXX`%{python3_byte_compile PATH}` XXX? Byte-compile a Python file into a `__pycache__/*.pyc`. See [Manual byte compilation](https://docs.fedoraproject.org/en-US/packaging-guidelines/Pyth… in the Appendix for usage. * `%{py_dist_name PROJECTNAME}` Given a *project name* (e.g. `PyYAML`) it will convert it to the canonical format (e.g. `pyyaml`). See *Canonical project name* for more information. * `%{py3_dist PROJECTNAME …}` Given one or more *project names*, it will convert them to the canonical format and evaluate to `python3dist(DISTNAME)`, which is useful when listing dependencies. See *Machine-readable provides* for more information. ### System Settings The following macros can be redefined for special use cases. Most of such cases are unacceptable in Fedora. * `%{__python}` (`/usr/bin/python`) Defining this macro changes the meaning of all “unversioned” Python macros such as `%{python}` or `%{python_sitelib}`. Don’t use these macros without redefining `%{__python}`. * `%{__python3}` (`/usr/bin/python3`) The python 3 interpreter. Redefining this macro changes all the `%{python3...}` macros, e.g. `%{python3_sitelib}`. * `%{python3_pkgversion}` (`3`) Distro-wide Python version, i.e. the `3` in `python3`. Projects that build on top of Fedora may define it to e.g. `3.9` to try allowing multiple Python stacks installable in parallel. ### XXX Conditionals? > XXX How to properly express: "if python_version >= 3.8"? > The current way is comparing integers from %python3_version_nodots, but that will break with 3.10/4.0 comparsion. > Do a Lua macro that splits the versions and compares them? > This looks more general, is there something in RPM we can use? ### Disabling automation The following macros can turn off Python-specific automation. Consider contacting the Python SIG if you need to do this. * `%{?python_disable_dependency_generator}` Disables the automatic dependency generator. See *Automatically generated dependencies* for details. * `%__pythonname_provides` > XXX undefine to disable %python-provides generator * `%__pythondist_requires` > XXX undefine to disable %python3dist generator ### Deprecated Macros The following macros are deprecated. See the *201x-era Python Packaging guidelines* (XXX link) for how some of them were used. * `%py3_build` * `%py3_build_wheel` * `%py3_build_egg` * `%py3_install` * `%py3_install_wheel` * `%py3_install_egg` * `%py3dir` * `%py3_other_build` * `%py3_other_install` * `%python_provide` (without `s` at the end) > XXX: `%pyX_build` breaks shebang when upstream already uses some flags (https://bugzilla.redhat.com/show_bug.cgi?id=1335203) -- should we document this in the old guidelines? ## Reviewer checklist > After the guidelines are done, distill the **MUST**s/**SHOULD**s here. > XXX: Do we need a checklist at all? > How do we keep it updated (which hasn't happened in the last N years)

8 40

help wanted with modern Python packaging macros (%generate_buildrequires, %tox)
by Felix Schwarz 16 Nov '20

16 Nov '20

Hi, I wanted to update python-dns-lexicon. Version 3.4 uses poetry and tox so I thought it would be a good idea to get a grip on %generate_buildrequires, %tox etc. Unfortunately I'm a bit stuck at the moment. Maybe this is just because I'm starring for too long on some spec file (and probably my knowledge of tox+macros is lacking). I pushed the current state to: https://src.fedoraproject.org/fork/fschwarz/rpms/python-dns-lexicon/commits… My main problem is shown at the end of this mail: Somehow the Python extras subpackage name is bad but I don't know how to debug this (without spending a lot of time). Additionally (but lower priority) just using %tox in %check fails (I think it tries to download dependencies?). Any help/pointers appreciated. Felix $ fedpkg --release=f33 mockbuild … Obsoletes: python-dns-lexicon < 3.4.0-1.fc33 Processing files: python3-dns-lexicon+easyname-3.4.0-1.fc33.noarch Error: The package name contains an extras name `easyname` that was not found in the metadata. Check if the extras were removed from the project. If so, consider removing the subpackage and obsoleting it from another. error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR *** Error: The package name contains an extras name `easyname` that was not found in the metadata. Check if the extras were removed from the project. If so, consider removing the subpackage and obsoleting it from another. error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR *** Provides: python-dns-lexicon+easyname = 3.4.0-1.fc33 python3-dns-lexicon+easyname = 3.4.0-1.fc33 python3.9-dns-lexicon+easyname = 3.4.0-1.fc33 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Obsoletes: python-dns-lexicon+easyname < 3.4.0-1.fc33 RPM build errors: absolute symlink: /usr/bin/lexicon-3 -> /usr/bin/lexicon-3.9 Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR *** Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR *** Finish: rpmbuild python-dns-lexicon-3.4.0-1.fc33.src.rpm Finish: build phase for python-dns-lexicon-3.4.0-1.fc33.src.rpm

2 3

Mass spec change: Replace Python 3 version globs (3.?) with macros to support 3.10
by Tomas Hrnciar 29 Oct '20

29 Oct '20

Hello everyone, with the upcoming Python 3.10 update we need to update Python 3 version globs in Fedora specfiles. The reason is simple, Python version will be one character longer so the currently omnipresent ?.? glob won't work anymore. We did this change a few months ago (see: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…) but we found out that the queries were incomplete, hence here is another update for the 3.? glob. We will replace such globs with the %{python3_version} macro using: $ sed -i -e 's/3\.?/%{python3_version}/g' *.spec There are currently 48 affected packages. $ grep -l 'py3.?' *.spec | wc -l 48 The sed can theoretically produce unwanted changes, but when guarded by the grep, we have verified it won't. You can observe the general diff of all affected specfiles at https://github.com/hrnciar/rpm-specs/commit/7224a5. We plan to do this in one week via a provenpackager. We will not bump the release number, nor add a changelog entry and hence we will also not rebuild the packages. The commit message will be: Replace Python version glob with macro (needed for Python 3.10+) If you want to fix this differently in your package, you don't need to let us know, just do it. If you want to opt out from this change, let us know (ideally with some reasoning). If you found a mistake in the diff, please do let us know. Regards, Tomáš Hrnčiar Maintainers by package: fonttools pnemade tagoh fusion-icon jskarvad marisa ueno nest ankursinha nototools mfabian pwu python-PyLEMS ankursinha python-bids-validator ankursinha python-brian2 ankursinha python-dipy ankursinha python-django-pytest bkabrda mrunge python-elasticsearch dbruno piotrp stevetraylen python-firehose athoscr dmalcolm python-fsleyes ankursinha python-fsleyes-props ankursinha python-fsleyes-widgets ankursinha python-fslpy ankursinha python-gccinvocation dmalcolm python-grabbit ankursinha python-httpretty jpopelka python-lazyarray ankursinha python-mpd2 ankursinha python-nilearn ankursinha python-nistats ankursinha python-petlink ankursinha python-pretend piotrp python-pybids ankursinha python-pyemd ankursinha python-pyfim ankursinha python-pylatex ankursinha python-pymatreader ankursinha python-pyphi ankursinha python-pyscaffold ankursinha python-pyzabbix piotrp python-rstcheck ankursinha python-simplewrap ignatenkobrain python-structlog piotrp python-tempdir rathann python-trollius iwienand mrunge python-tvb-data ankursinha python-tvb-gdist ankursinha python-tzlocal ankursinha piotrp python-vconnector raphgro python-whitenoise ngompa piotrp python-xdot dmalcolm rb_libtorrent fale mooninite simple-ccsm jskarvad vimiv ankursinha zanata-python-client anishpatil dchen jamesni pnemade robyduck seanf suanand Packages by maintainer: anishpatil zanata-python-client ankursinha nest python-PyLEMS python-bids-validator python-brian2 python-dipy python-fsleyes python-fsleyes-props python-fsleyes-widgets python-fslpy python-grabbit python-lazyarray python-mpd2 python-nilearn python-nistats python-petlink python-pybids python-pyemd python-pyfim python-pylatex python-pymatreader python-pyphi python-pyscaffold python-rstcheck python-tvb-data python-tvb-gdist python-tzlocal vimiv athoscr python-firehose bkabrda python-django-pytest dbruno python-elasticsearch dchen zanata-python-client dmalcolm python-firehose python-gccinvocation python-xdot fale rb_libtorrent ignatenkobrain python-simplewrap iwienand python-trollius jamesni zanata-python-client jpopelka python-httpretty jskarvad fusion-icon simple-ccsm mfabian nototools mooninite rb_libtorrent mrunge python-django-pytest python-trollius ngompa python-whitenoise piotrp python-elasticsearch python-pretend python-pyzabbix python-structlog python-tzlocal python-whitenoise pnemade fonttools zanata-python-client pwu nototools raphgro python-vconnector rathann python-tempdir robyduck zanata-python-client seanf zanata-python-client stevetraylen python-elasticsearch suanand zanata-python-client tagoh fonttools ueno marisa

1 1

PythonMacroError change tripping up fedora-review on Python packages?
by Michel Alexandre Salim 28 Oct '20

28 Oct '20

When reviewing python-TestSlide (https://bugzilla.redhat.com/show_bug.cgi?id=1891963#) fedora-review failed with: error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly This seems related to the change introduced in F33: https://fedoraproject.org/wiki/Changes/PythonMacroError but we're a bit puzzled as to how it happens since we can't find any macro usage that expands to %__python. Out of curiosity I checked out python-six (fedpkg clone python-six && cd python-six && fedpkg srpm) and ran fedora-review on it, and it failed with the same error; likewise the spec seems valid to me. Any idea what could be the problem here? Thanks in advance! ❯ fedora-review --rpm-spec --name ./python-six-1.15.0-2.fc34.src.rpm INFO: Processing local files: ./python-six-1.15.0-2.fc34.src.rpm INFO: Getting .spec and .srpm Urls from : Local files in /home/michel/src/fedora/other-pkgs/python-six INFO: --> SRPM url: file:///home/michel/src/fedora/other-pkgs/python- six/python-six-1.15.0-2.fc34.src.rpm INFO: Using review directory: /home/michel/src/fedora/other- pkgs/python-six/python-six INFO: Downloading (Source0): https://files.pythonhosted.org/packages/source/s/six/six-1.15.0.tar.gz INFO: Running checks and generating report INFO: Results and/or logs in: /home/michel/src/fedora/other- pkgs/python-six/python-six/results INFO: Reading configuration from /etc/mock/site-defaults.cfg INFO: Reading configuration from /etc/mock/fedora-rawhide-x86_64.cfg INFO: Build completed INFO: Installing built package(s) INFO: Active plugins: Shell-api, Python, Generic error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly ERROR: Exception down the road... (logs in /home/michel/.cache/fedora- review.log) -- Michel Alexandre Salim profile: https://keyoxide.org/michel@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

2 2

Help with segfaulting python code
by Orion Poplawski 27 Oct '20

27 Oct '20

I've attempted to update python-pyface to 7.1.0 in Rawhide, however a test is segfaulting. I've reported upstream here: https://github.com/enthought/pyface/issues/784 but perhaps someone with knowledge of Python internals might be able to see what is up better. It's segfaulting due to _PyThreadState_GET() returning NULL. Google searches seem to indicate that this can happen when python binaries and run time libraries get out of sync, but I'm not sure that can be happening here. There is a very simple reproducer in the bug report. Thanks, Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 1

Disk space minimization of Python
by Tomas Orsava 14 Oct '20

14 Oct '20

Hi, I have opened an upstream discussion about disk space minimization of Python, take a look: https://discuss.python.org/t/disk-space-minimization-for-python-distributor… All the best, Tomas

1 0

Follow-up - Please BuildRequire python3-setuptools explicitly
by Tomas Hrnciar 08 Oct '20

08 Oct '20

Hello everyone, this is a follow-up email to the one I wrote a couple of months ago ( https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…) . Below is the original text with reasoning and an updated list of remaining packages to be updated. There are plenty of Python packages in Fedora currently using setuptools at buildtime but not all of them are BuildRequiring it explicitly. This only works because python3-devel (transitively) depends on python3-setuptools. We would like to kindly ask you to add explicit BuildRequires for python3-setuptools to packages where setuptools is used. It will help us with testing new versions of setuptools in the future or with decoupling Python and setuptools. Today, if we want to know if a package is using setuptools, we have to do `fedpkg prep` and use grep to search for setuptools. Using a repoquery is much more convenient. Several packages can successfully build either with or without setuptools (they use try-except import and fallback to distutils from the standard library). Such packages are especially dangerous when not BuildRequiring setuptools -- they can produce different results depending on the presence of setuptools: either an .egg-info metadata directory (w/setuptools) or .egg-info text file (w/distutils). RPM has troubles when upgrading directories to files [1]. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replace… According to our grep based query on Fedora Rawhide, there are 382 known packages using setuptools without BuildRequiring it at this point. Thank you very much for your help with this. On behalf of python-setuptools maintainers, Tomáš Hrnčiar Maintainers by package: OpenMolcas jussilehtola PyGreSQL hhorak jmlich odubaj panovotn pkajaba pkubat praiskup R2spec pingou ViTables tnorth zbyszek ansible-review dcallagh ttrinks arbor ankursinha barman slaanesh tsao blender design-sw hobbes1069 ignatenkobrain kwizart luya roma s4504kr slaanesh bumpversion duriantang jdornak calypso rathann cinch greghellings commissaire-client mbarnes smilner condor bbockelm bcotton eerlands matt matyas stevetraylen tstclair ttheisen valtri copr-messaging schlupov cppcheck c72578 jussilehtola sgrubb cranc lenkaseg crudini apevec jruzicka pbrady cxxtest mgieseki datanommer ralph electrum jonny fail2ban atkac hobbes1069 jgu orion fedora-messaging abompard fontforge frixxon kevin pnemade gajim michich gau2grid jussilehtola gfal2-python adev andreamanzi gbitzes ginga lupinix git-filter-repo asn git-up mhjacks gmsh hobbes1069 ignatenkobrain jkastner smani gnofract4d jjames gns3-gui kwizart gns3-net-converter kwizart gns3-server kwizart nucleo grammalecte melmorabity h5py stevetraylen terjeros hgview kiilerix httpie codeblock ralph icecat jenslody kengert sagitter kf5-kapidox dvratil jgrulich rdieter than kismon fab koji ausil kevin mikem puiterwijk legendary atim legofy lkf williamjmorenor libcaca hubbitus slaanesh thias lldb airlied daveisfera jankratochvil sergesanspaille siddharths tstellar llvm dmalcolm ignatenkobrain jakub jistone kyle scottt sergesanspaille siddharths tstellar llvm10 sergesanspaille tstellar llvm7.0 jistone petersen sergesanspaille tstellar llvm9.0 jistone sergesanspaille tstellar mercurial kiilerix nbecker pstodulk mgarepo misc ngompa minigalaxy atim mod_wsgi jdornak jkaluza jorton lmacken mrunge modulemd-tools frostyx moose zbyszek mypaint avsej mysql-connector-python hhorak hubbitus hvad mschorm nextpnr lkundrak somlo nodejs mrunge patches piotrp sgallagh zvetlik nototools mfabian pwu officeparser rebus offlineimap cicku dodji sergesanspaille teuf pcp2pdf lberk mbaldessari percol hubbitus picard alexlan cicku gbcox ohaessler pipsi orphan pipx mhjacks poezio fantom louizatakk porcupine kushal protonvpn-cli jflory7 prunerepo clime frostyx pyaudio chkr pygobject3 johnp nacho walters pyhunspell mfabian pyodbc fjanus hhorak pyosmium tomh pyscard sjenning pyserial stingray python-CommonMark jujens python-GridDataFormats rathann python-OBD rathann python-Pyped uggla python-Rtree volter python-acoustid terjeros python-agate jujens python-aiodns fantom python-ansicolors orphan python-apprise lead2gold python-apsw cicku dfateyev maci python-arviz sergiopr python-astroplan sergiopr python-astropy-healpix lupinix python-astroquery lupinix python-astroscrappy lupinix python-asttokens zbyszek python-audioread terjeros python-autobahn fab jujens python-autopep8 mrunge ndipanov python-babelfish jorti python-bigsuds xavierb python-bloom cottsay rmattes python-blosc tnorth zbyszek python-box dmsimard fab python-btchip jonny xenithorb python-cached_property adamwill immanetize python-carbon jsteffan piotrp python-ccdproc lupinix python-certbot-apache jhogarth nb python-chai kevin pingou ralph python-click-plugins qulogic python-cloud-sptheme kevin ralph python-cmigemo hubbitus python-colorspacious rathann python-construct moezroy terjeros python-contextlib2 abompard pingou ralph tjikkun python-cookiecutter chedi wakko666 python-crochet abompard python-css-parser zbyszek python-dbfread jujens python-debrepo ktdreyer python-decopatch zbyszek python-descartes qulogic python-dialog itamarjp mjakubicek noodles raphgro sundaram zbyszek python-dijitso zbyszek python-dill sergiopr python-django-contact-form mrunge python-django-health-check dmsimard python-django-registration kumarpraveen python-django-reversion mrunge python-django-tagging jdornak mrunge piotrp python-django-tastypie bkabrda cquad mrunge stevetraylen python-docx kushal124 python-dpkt mbaldessari python-dtfabric fab python-dukpy zbyszek python-editorconfig barracks510 python-emcee sergiopr python-enzyme jorti python-ephem fab python-et_xmlfile jujens python-etcd mbarnes smilner python-factory-boy jorti python-faker jorti python-fasteners mrunge python-ffc zbyszek python-fields cottsay python-fisx zbyszek python-fitsio lupinix python-flake8-docstrings cottsay python-flask-gravatar devrim itamarjp python-flask-htmlmin devrim itamarjp python-flask-paranoid devrim itamarjp python-flask-security devrim itamarjp python-flask-sphinx-themes devrim itamarjp python-flask-wtf-decorators frostyx python-formats uggla python-fuse jorti python-fypp rathann python-gevent dcallagh ignatenkobrain orion skottler python-graphql-relay fab python-gsd rathann python-guessit jorti python-heapdict qulogic python-html5-parser kevin python-htmlmin jujens python-humblewx rickardlindberg python-hupper kevin python-i3ipc msimacek python-inotify jfilak stevetraylen terjeros python-iso-639 melmorabity python-iso3166 melmorabity python-jep raphgro python-jinja2-cli jujens python-jinja2-time chedi wakko666 python-jnius raphgro python-joblib besser82 ignatenkobrain sergiopr python-journal-brief twaugh python-jsonmodels oanson python-jsonrpclib ihrachyshka jonny python-junit_xml jhogarth python-kaitaistruct rathann python-kerberos rcritten simo python-kitchen kevin pingou ralph python-kiwisolver qulogic python-landslide echevemaster salimma python-lark-parser totol python-leather jujens python-libsass dormouse python-libusb1 jonny python-lmdb pspacek python-makefun zbyszek python-mapnik tomh python-mdp zbyszek python-meld3 kevin stevetraylen tsao python-minibelt uggla python-mmtf rathann python-mnemonic jonny python-music21 zbyszek python-mutagen cicku ignatenkobrain mbaldessari moezroy python-mwclient adamwill rdieter tuxbrewr python-myhdl filiperosset python-nbxmpp michich python-networkmanager jdulaney python-notario ktdreyer python-oauth2 ignatenkobrain pjp spot sundaram python-octave-kernel qulogic python-openoffice sharkcz python-ouimeaux kni python-pandas-datareader sergiopr python-partd qulogic python-paste-script andreamanzi dcallagh python-patsy sergiopr python-pbkdf2 jonny python-pecan-notario ktdreyer python-pelican firemanxbr mrunge python-pep8-naming qulogic python-petlink ankursinha python-pexpect amcnabb fabiand ignatenkobrain radez swt2c tomspur python-photutils sergiopr python-plaster-pastedeploy abompard python-plumbum greghellings lorenzodalrio python-polib cicku dchen diegobz dshea ivazquez moezroy suanand python-precis_i18n michich python-proteus sharkcz python-publicsuffix2 rathann python-pulsectl pfrields python-pvc raphgro python-pycares fantom python-pycha potty sharkcz python-pygeoip kevin ralph python-pylons-sphinx-themes abompard python-pymc3 sergiopr python-pyotp icon python-pypng kevin ralph python-pyramid_sawing abompard python-pysb zbyszek python-pysignals kni python-pysrt jorti python-pytest-astropy-header sergiopr python-pytest-benchmark jorti python-pytest-cases zbyszek python-pytest-fixture-config kevin python-pytest-harvest zbyszek python-pytest-mock fab jujens python-pytest-repeat cottsay python-pytest-shutil kevin python-pytest-steps zbyszek python-pytest-virtualenv kevin python-pytest-watch jujens python-pyvo lupinix python-rebulk jorti python-recommonmark jujens python-relatorio sharkcz python-rencode jgu orion patches python-restructuredtext-lint jujens python-retrying apevec python-rmtest lberk mgoodwin nathans python-rosdep cottsay rmattes thofmann python-rpmautospec asaleh nphilipp python-sanction kevin ralph python-scikit-learn besser82 ignatenkobrain lupinix sergiopr python-scrapy echevemaster python-setuptools-lint jdulaney python-shamir-mnemonic jonny python-sieve kevin ondrejj ralph python-simplemediawiki lmacken potty ralph python-simpleparse grover mlombard python-slixmpp fantom louizatakk python-snappy jujens python-social-auth-core cqi python-soupsieve zbyszek python-spdx jbertozzi python-spdx-lookup jbertozzi python-sphinx-copybutton jjames python-sphinxcontrib-issuetracker fab orion python-sql sharkcz python-statsd pabelanger tdecacqu python-statsmodels sergiopr python-subliminal jorti python-tables tnorth zbyszek python-tblib qulogic python-tempdir rathann python-timeout-decorator jcapitao python-tinydb suanand python-tortilla uggla python-tree-format chedi wakko666 python-trezor jonny python-twilio mich181189 python-txaio fab jujens python-unidecode pjp sundaram python-unidiff dcallagh python-upt-cpan jbertozzi python-upt-fedora jbertozzi python-upt-pypi jbertozzi python-upt-rubygems jbertozzi python-urwidtrees ttomecek python-wand barracks510 python-watchdog jsteffan jujens pingou python-webencodings abompard python-webpy mrunge python-winrm jhogarth python-wsaccel jujens python-xlib jspaleta orion potty python-xlwt leamas moezroy rathann python-xvfbwrapper mrunge totol python-zict qulogic python-zstandard rathann python3-py3dns bojan kevin ralph python3-pytest-asyncio jujens python3-saml dcallagh tchaikov rdkit giallu rpmspectool nphilipp salt blarson dmurphy18 jshatch scons fab moceap mskalick panovotn s4504kr sagitter scribus pwalter sharkcz sentencepiece kenhys sepolicy_analysis vmojzis solaar brouhaha rathann richardfearn tibbs sos-collector turboturtle spec2scl jstanek starcal hedayat stomppy stevetraylen sugar-speak callkalpa chimosky pbrobinson tuxbrewr swid-tools adelton thrift ctubbsii milleruntime orion toot alciregi tortoisehg kiilerix nbecker translate-toolkit cicku dwayne petersen suanand tryton sharkcz trytond sharkcz trytond-account sharkcz trytond-account-be sharkcz trytond-account-de-skr03 sharkcz trytond-account-invoice sharkcz trytond-account-invoice-history sharkcz trytond-account-invoice-line-standalone sharkcz trytond-account-product sharkcz trytond-account-statement sharkcz trytond-account-stock-anglo-saxon sharkcz trytond-account-stock-continental sharkcz trytond-analytic-account sharkcz trytond-analytic-invoice sharkcz trytond-analytic-purchase sharkcz trytond-analytic-sale sharkcz trytond-company sharkcz trytond-company-work-time sharkcz trytond-country sharkcz trytond-currency sharkcz trytond-dashboard sharkcz trytond-google-maps sharkcz trytond-ldap-authentication sharkcz trytond-party sharkcz trytond-party-siret sharkcz trytond-product sharkcz trytond-product-cost-fifo sharkcz trytond-product-cost-history sharkcz trytond-product-price-list sharkcz trytond-project sharkcz trytond-project-plan sharkcz trytond-project-revenue sharkcz trytond-purchase sharkcz trytond-purchase-invoice-line-standalone sharkcz trytond-sale sharkcz trytond-sale-opportunity sharkcz trytond-sale-price-list sharkcz trytond-stock sharkcz trytond-stock-forecast sharkcz trytond-stock-inventory-location sharkcz trytond-stock-location-sequence sharkcz trytond-stock-product-location sharkcz trytond-stock-supply sharkcz trytond-stock-supply-day sharkcz trytond-timesheet sharkcz uhd jskarvad upt jbertozzi uwsgi kad winpdb spot xrootd ellert simonm xtensor-python sergesanspaille yawn jsafrane miminar vcrhonek yubikey-manager gbcox sjenning Packages by maintainer: abompard fedora-messaging python-contextlib2 python-crochet python-plaster-pastedeploy python-pylons-sphinx-themes python-pyramid_sawing python-webencodings adamwill python-cached_property python-mwclient adelton swid-tools adev gfal2-python airlied lldb alciregi toot alexlan picard amcnabb python-pexpect andreamanzi gfal2-python python-paste-script ankursinha arbor python-petlink apevec crudini python-retrying asaleh python-rpmautospec asn git-filter-repo atim legendary minigalaxy atkac fail2ban ausil koji avsej mypaint barracks510 python-editorconfig python-wand bbockelm condor bcotton condor besser82 python-joblib python-scikit-learn bkabrda python-django-tastypie blarson salt bojan python3-py3dns brouhaha solaar c72578 cppcheck callkalpa sugar-speak chedi python-cookiecutter python-jinja2-time python-tree-format chimosky sugar-speak chkr pyaudio cicku offlineimap picard python-apsw python-mutagen python-polib translate-toolkit clime prunerepo codeblock httpie cottsay python-bloom python-fields python-flake8-docstrings python-pytest-repeat python-rosdep cqi python-social-auth-core cquad python-django-tastypie ctubbsii thrift daveisfera lldb dcallagh ansible-review python-gevent python-paste-script python-unidiff python3-saml dchen python-polib design-sw blender devrim python-flask-gravatar python-flask-htmlmin python-flask-paranoid python-flask-security python-flask-sphinx-themes dfateyev python-apsw diegobz python-polib dmalcolm llvm dmsimard python-box python-django-health-check dmurphy18 salt dodji offlineimap dormouse python-libsass dshea python-polib duriantang bumpversion dvratil kf5-kapidox dwayne translate-toolkit echevemaster python-landslide python-scrapy eerlands condor ellert xrootd fab kismon python-autobahn python-box python-dtfabric python-ephem python-graphql-relay python-pytest-mock python-sphinxcontrib-issuetracker python-txaio scons fabiand python-pexpect fantom poezio python-aiodns python-pycares python-slixmpp filiperosset python-myhdl firemanxbr python-pelican fjanus pyodbc frixxon fontforge frostyx modulemd-tools prunerepo python-flask-wtf-decorators gbcox picard yubikey-manager gbitzes gfal2-python giallu rdkit greghellings cinch python-plumbum grover python-simpleparse hedayat starcal hhorak PyGreSQL mysql-connector-python pyodbc hobbes1069 blender fail2ban gmsh hubbitus libcaca mysql-connector-python percol python-cmigemo hvad mysql-connector-python icon python-pyotp ignatenkobrain blender gmsh llvm python-gevent python-joblib python-mutagen python-oauth2 python-pexpect python-scikit-learn ihrachyshka python-jsonrpclib immanetize python-cached_property itamarjp python-dialog python-flask-gravatar python-flask-htmlmin python-flask-paranoid python-flask-security python-flask-sphinx-themes ivazquez python-polib jakub llvm jankratochvil lldb jbertozzi python-spdx python-spdx-lookup python-upt-cpan python-upt-fedora python-upt-pypi python-upt-rubygems upt jcapitao python-timeout-decorator jdornak bumpversion mod_wsgi python-django-tagging jdulaney python-networkmanager python-setuptools-lint jenslody icecat jfilak python-inotify jflory7 protonvpn-cli jgrulich kf5-kapidox jgu fail2ban python-rencode jhogarth python-certbot-apache python-junit_xml python-winrm jistone llvm llvm7.0 llvm9.0 jjames gnofract4d python-sphinx-copybutton jkaluza mod_wsgi jkastner gmsh jmlich PyGreSQL johnp pygobject3 jonny electrum python-btchip python-jsonrpclib python-libusb1 python-mnemonic python-pbkdf2 python-shamir-mnemonic python-trezor jorti python-babelfish python-enzyme python-factory-boy python-faker python-fuse python-guessit python-pysrt python-pytest-benchmark python-rebulk python-subliminal jorton mod_wsgi jruzicka crudini jsafrane yawn jshatch salt jskarvad uhd jspaleta python-xlib jstanek spec2scl jsteffan python-carbon python-watchdog jujens python-CommonMark python-agate python-autobahn python-dbfread python-et_xmlfile python-htmlmin python-jinja2-cli python-leather python-pytest-mock python-pytest-watch python-recommonmark python-restructuredtext-lint python-snappy python-txaio python-watchdog python-wsaccel python3-pytest-asyncio jussilehtola OpenMolcas cppcheck gau2grid kad uwsgi kengert icecat kenhys sentencepiece kevin fontforge koji python-chai python-cloud-sptheme python-html5-parser python-hupper python-kitchen python-meld3 python-pygeoip python-pypng python-pytest-fixture-config python-pytest-shutil python-pytest-virtualenv python-sanction python-sieve python3-py3dns kiilerix hgview mercurial tortoisehg kni python-ouimeaux python-pysignals ktdreyer python-debrepo python-notario python-pecan-notario kumarpraveen python-django-registration kushal porcupine kushal124 python-docx kwizart blender gns3-gui gns3-net-converter gns3-server kyle llvm lberk pcp2pdf python-rmtest lead2gold python-apprise leamas python-xlwt lenkaseg cranc lkf legofy lkundrak nextpnr lmacken mod_wsgi python-simplemediawiki lorenzodalrio python-plumbum louizatakk poezio python-slixmpp lupinix ginga python-astropy-healpix python-astroquery python-astroscrappy python-ccdproc python-fitsio python-pyvo python-scikit-learn luya blender maci python-apsw matt condor matyas condor mbaldessari pcp2pdf python-dpkt python-mutagen mbarnes commissaire-client python-etcd melmorabity grammalecte python-iso-639 python-iso3166 mfabian nototools pyhunspell mgieseki cxxtest mgoodwin python-rmtest mhjacks git-up pipx mich181189 python-twilio michich gajim python-nbxmpp python-precis_i18n mikem koji milleruntime thrift miminar yawn misc mgarepo mjakubicek python-dialog mlombard python-simpleparse moceap scons moezroy python-construct python-mutagen python-polib python-xlwt mrunge mod_wsgi nodejs python-autopep8 python-django-contact-form python-django-reversion python-django-tagging python-django-tastypie python-fasteners python-pelican python-webpy python-xvfbwrapper mschorm mysql-connector-python msimacek python-i3ipc mskalick scons nacho pygobject3 nathans python-rmtest nb python-certbot-apache nbecker mercurial tortoisehg ndipanov python-autopep8 ngompa mgarepo noodles python-dialog nphilipp python-rpmautospec rpmspectool nucleo gns3-server oanson python-jsonmodels odubaj PyGreSQL ohaessler picard ondrejj python-sieve orion fail2ban python-gevent python-rencode python-sphinxcontrib-issuetracker python-xlib thrift orphan pipsi python-ansicolors pabelanger python-statsd panovotn PyGreSQL scons patches nodejs python-rencode pbrady crudini pbrobinson sugar-speak petersen llvm7.0 translate-toolkit pfrields python-pulsectl pingou R2spec python-chai python-contextlib2 python-kitchen python-watchdog piotrp nodejs python-carbon python-django-tagging pjp python-oauth2 python-unidecode pkajaba PyGreSQL pkubat PyGreSQL pnemade fontforge potty python-pycha python-simplemediawiki python-xlib praiskup PyGreSQL pspacek python-lmdb pstodulk mercurial puiterwijk koji pwalter scribus pwu nototools qulogic python-click-plugins python-descartes python-heapdict python-kiwisolver python-octave-kernel python-partd python-pep8-naming python-tblib python-zict radez python-pexpect ralph datanommer httpie python-chai python-cloud-sptheme python-contextlib2 python-kitchen python-pygeoip python-pypng python-sanction python-sieve python-simplemediawiki python3-py3dns raphgro python-dialog python-jep python-jnius python-pvc rathann calypso python-GridDataFormats python-OBD python-colorspacious python-fypp python-gsd python-kaitaistruct python-mmtf python-publicsuffix2 python-tempdir python-xlwt python-zstandard solaar rcritten python-kerberos rdieter kf5-kapidox python-mwclient rebus officeparser richardfearn solaar rickardlindberg python-humblewx rmattes python-bloom python-rosdep roma blender s4504kr blender scons sagitter icecat scons salimma python-landslide schlupov copr-messaging scottt llvm sergesanspaille lldb llvm llvm10 llvm7.0 llvm9.0 offlineimap xtensor-python sergiopr python-arviz python-astroplan python-dill python-emcee python-joblib python-pandas-datareader python-patsy python-photutils python-pymc3 python-pytest-astropy-header python-scikit-learn python-statsmodels sgallagh nodejs sgrubb cppcheck sharkcz python-openoffice python-proteus python-pycha python-relatorio python-sql scribus tryton trytond trytond-account trytond-account-be trytond-account-de-skr03 trytond-account-invoice trytond-account-invoice-history trytond-account-invoice-line-standalone trytond-account-product trytond-account-statement trytond-account-stock-anglo-saxon trytond-account-stock-continental trytond-analytic-account trytond-analytic-invoice trytond-analytic-purchase trytond-analytic-sale trytond-company trytond-company-work-time trytond-country trytond-currency trytond-dashboard trytond-google-maps trytond-ldap-authentication trytond-party trytond-party-siret trytond-product trytond-product-cost-fifo trytond-product-cost-history trytond-product-price-list trytond-project trytond-project-plan trytond-project-revenue trytond-purchase trytond-purchase-invoice-line-standalone trytond-sale trytond-sale-opportunity trytond-sale-price-list trytond-stock trytond-stock-forecast trytond-stock-inventory-location trytond-stock-location-sequence trytond-stock-product-location trytond-stock-supply trytond-stock-supply-day trytond-timesheet siddharths lldb llvm simo python-kerberos simonm xrootd sjenning pyscard yubikey-manager skottler python-gevent slaanesh barman blender libcaca smani gmsh smilner commissaire-client python-etcd somlo nextpnr spot python-oauth2 winpdb stevetraylen condor h5py python-django-tastypie python-inotify python-meld3 stomppy stingray pyserial suanand python-polib python-tinydb translate-toolkit sundaram python-dialog python-oauth2 python-unidecode swt2c python-pexpect tchaikov python3-saml tdecacqu python-statsd terjeros h5py python-acoustid python-audioread python-construct python-inotify teuf offlineimap than kf5-kapidox thias libcaca thofmann python-rosdep tibbs solaar tjikkun python-contextlib2 tnorth ViTables python-blosc python-tables tomh pyosmium python-mapnik tomspur python-pexpect totol python-lark-parser python-xvfbwrapper tsao barman python-meld3 tstclair condor tstellar lldb llvm llvm10 llvm7.0 llvm9.0 ttheisen condor ttomecek python-urwidtrees ttrinks ansible-review turboturtle sos-collector tuxbrewr python-mwclient sugar-speak twaugh python-journal-brief uggla python-Pyped python-formats python-minibelt python-tortilla valtri condor vcrhonek yawn vmojzis sepolicy_analysis volter python-Rtree wakko666 python-cookiecutter python-jinja2-time python-tree-format walters pygobject3 williamjmorenor legofy xavierb python-bigsuds xenithorb python-btchip zbyszek ViTables moose python-asttokens python-blosc python-css-parser python-decopatch python-dialog python-dijitso python-dukpy python-ffc python-fisx python-makefun python-mdp python-music21 python-pysb python-pytest-cases python-pytest-harvest python-pytest-steps python-soupsieve python-tables zvetlik nodejs

3 2

python-flit updated to 3.0.0
by Tomas Hrnciar 02 Oct '20

02 Oct '20

Hello everyone, python-flit was updated to version 3.0.0 in rawhide. Flit now requires metadata in pyproject.toml file instead of flit.init. We have fixed 2 Fedora packages affected by this change so there is no action needed from your side. This is just a heads up in case you will use Flit in the future. See the full changelog at https://flit.readthedocs.io/en/latest/history.html#version-3-0. Have a nice day. Tomáš Hrnčiar

1 0

pyproject macros update: No RECORDs, %pyproject_buildrequires supports multiple -x options and tox extras
by Miro Hrončok 01 Oct '20

01 Oct '20

Hello Pythonistas. A new version of pyproject-rpm-macros (0-30) is out there. There are 3 significant changes: 1) The RECORD and REQUESTED files are removed from dist-info directories. This is to line up with https://www.python.org/dev/peps/pep-0627/ created by Petr Viktorin. Basically, Python packages installed via RPM should not be managed by pip. As a direct result, it is not possible to sudo pip uninstall them. It is still possible to sudo pip install --upgrade them to /usr/local. 2) It is possible to use %pyproject_buildrequires with multiple -x options, like this: %pyproject_buildrequires -x plesk -x route53. Previously, a single comma-separated value needed: %pyproject_buildrequires -x plesk,route53. The change is backwards compatible (comma separated values are still possible, even multiple). 3) Extras specified in toxenv configuration are installed when %pyproject_buildrequires is used with -t/-e. For example, with this tox config: [testenv] ... extras = dev full The dependencies of the [dev] and [full] extras are installed (similarly to %pyproject_buildrequires -x dev -x full). We hope the changes will make it easier for you to adapt the macros. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel October 2020