With `pyp2spec <pkgname> --path /pth/to/artifacts` a specfile will be
now generated from data available in sdist and wheel.
The `--path` option takes as a value a directory where the built artifacts
are stored.
When specified on command line, a compat package for a given version
will be created.
pyp2spec will create a specfile for the latest version matching the
compat one, e.g. for `pytest --compat 7` it will create specfile for
version 7.4.4; for `pytest --compat 7.2` - 7.2.2.
It is possible to specify both compat and specific version, e.g.:
`pytest --compat 7 --version 7.3.0`
The new create_package_from_source takes care of creating the package object
and the "old" create_config_contents only modifies the bits needed for
the full config file.
This serves as a sort of contract, as opposed to a plain dictionary.
This enables control over all of the attributes and makes it reasonably
sure nothing gets unexpectedly mixed in.
The refactor contains changes:
- core metadata coming from the Metadata file are the canonical source
of truth to gather package info
- the archive metadata are still obtained from PyPI API, as core
metadata don't include any information about them
- OOP approach is refactored to the functional one to achieve clearer
design of multiple data sources and better testability of the
particular functions
- pyp2conf now contains only the logic of the actual data assembly, all
the helper methods are moved to the pypi_loaders, utils and
license_processor
(Effectively revert the removals done to implement PEP 625).
The removal was too haste and broke the users.
This reverts commit 9747b76c4f
and builds on top of the changes in between.
pyp2conf shouldn't be so heavy with RPM-specific data.
The data stored in the config file are the ones read from either the
PyPI API or Metadata file.
Everything related to transformations to specfiles is now stored in
conf2spec. It reads the config data and converts them to RPM-specific
format.
Ideally, if pyproject-rpm-macros become obsolete and a new system comes
in place, the only changes would be applicable on the side of conf2spec.
The sdist filenames are now standardized:
- distribution name is normalized similarly to the project names, but
with "_" instead of "-"
- version string is expected to be PEP 440 compliant
- the supported file extension is tar.gz, zip is gone
Always test the whole config contents even if the test is about a single
feature.
This ensures no regressions are accidentally introduced and ensures
wanted updates when recreating cassettes.
If "License-File" is present in Metadata file, we can safely add the
`-l` flag to %pyproject_save_files. The flag asserts that at least
one license file is marked as %license in the %files section
when there are none specified manually.
Not all build backends expose the field yet, which was oficially added
to Core Metadata 2.4 with PEP 639.
Yellow - operating on the discovered information
Magenta - requires attention, not bad per se
Red - something bad has happened
Also, done cosmetic changes to the printed sentences, ain't noboody got
time to read novels.
For automated environments, we want to ensure buildability of the
created specfile, hence adding `"*" +auto` to %pyproject_save_files.
In the real Fedora packages, the valid argument to %pyproject_save_files
is a list of module names.
For now there's no automatic way to discover what modules the package
contains, so when a human user invokes pyp2spec, we want to generate a
file with placeholder (...) for them to fill in after the package
inspection.
- Utilize the new macro %_pyproject_check_import_allow_no_modules to allow
passing check in automated environments, even when the package doesn't
contain any Python modules (fixes#31).
This feature is useful when creating packages for Centos Stream and RHEL
which contain multiple Python stacks and make it possible to build packages for
them.
Packages on PyPI publish wheels which contain an abi tag informing
whether a package contains extensions compiled for a specific
architecture or not.
pyp2conf reads this information and saves it in the config file.
conf2spec automatically adds `gcc` to the generated specfile in case
package is archful.
They were partially defunct, made no actual sense and need to be
forgotten without mercy.
Generating extras for %pyproject_buildrequires (-x foo) will be improved.
For tox dependencies (-t), the users can manually add it to the resulting
spec file.
Create extra subpackages for all of the detected upstream extras.
Due to PyPI API limitations, if an extra is defined as empty
(i.e. without any requirements), it won't be detected.
It is an inherent package property rather than an external factor.
It is the key differentiator for obtaining the package metadata (they
must match the given version release).
Instead of raising multiple sys.exit's throughout the code,
each function either returns a proper value or raises a meaningful
custom error.
The custom errors are caught in each script's main(),
the error message is printed for user and the script exits.
Alongside with the license-related code the tests were significantly
refactored to run offline. The changes are intertwined and so shipped in
a single commit.
The licensing changes:
- updated Trove-Fedora mappings (removed Callaway expressions, added
SPDX)
- delegated the compliance check of Fedora licenses to a source
maintained by the Fedora Legal team
- the logic of license processing was moved to a dedicated module:
license_processor
The testing changes:
- moved betamax configuration to conftest.py to achieve a reliable global setting
- mocked fedora licensing data and PyPI package data to stop making
unnecessary requests - most of the betamax cassettes were deleted
- several tests rewritten, many added
- regenerated remaining betamax cassettes
This is a best-effort solution which can't (nor aims to) cover all edge-cases.
Unless Python adopts SPDX standard, this will always be an approximation.
- Replace underscores and dots with dashes in projects' names
Projects like sphinx_design result in python-sphinx-design.spec
and python3-sphinx-design built RPM name.
- Convert uppercase characters to lowercase
Projects like Pello result in python-pello.spec and python3-pello
built RPM name.
This conforms better with package naming guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_naming