⚠️⚠️⚠️ This project needs new maintainers ⚠️⚠️⚠️
Opened this issue · 22 comments
All of the original contributors are gone from Fedora. And I unfortunately don't have time for pyp2rpm other than dealing with very critical bugs.
@gordonmessmer was very active recently in pyp2rpm and I'd like to pass the project to him, if interested.
Sure, I'm interested.
@gordonmessmer I've made you and admin. Will be around to answer questions.
Next release, will coordinate with you and give right on PyPI.
@decathorpe You want to get involved as well?
@hroncok if there's something I can help with, and I have some time, sure.
I use pyp2rpm for every new python package, after all :)
There are several open pull requests in here. Getting them reviewed/updated/merged (or closed) is a good way to contribute here.
In the near term, I'd like to:
-
Resolve an issue with a corner case for converting python packaging requirements to rpm (https://github.com/gordonmessmer/pyreq2rpm/)
-
Go over #196 and make sure that all of the requirement conversions match pyreq2rpm, and fix anything that doesn't.
-
#196 introduces a micro-test module rather than pulling a third-party python module into git. My preference is not to commit blobs to git, generally, and to avoid potential licensing issues arising from including third-party code [1], but I'd like to know if anyone else has thoughts. That may inform the review of PRs currently open that include new modules in tests.
-
Tests for #215 fail for setup in python2; we should fix that if possible, but we also know that python2 support is slated for removal in the future
-
Publish a new version
-
Close all of the open issues that have been resolved
-
Bump the major version number and remove python2 support. Distributions still shipping python2 can still use the last version, and if we really need to bugfix we can create a branch from that point to build additional bugfix releases.
-
We should make sure there's a license for each of the modules we already include: https://snyk.io/blog/over-10-of-python-packages-on-pypi-are-distributed-without-any-license/
@gordonmessmer what is the status of this ticket (and whole project)? This ticket seems like untouched since 2020, but you send some commits here earlier this year. Asking because I was thinking about reviving our own https://github.com/openSUSE/py2pack/ and now I wonder whether I shouldn’t just join your effort here.
Well, I certainly think that more new maintainers are still needed and would be welcome, so I left this ticket open after becoming a maintainer.
I haven't been as active or available as I would like recently, after starting a new job last year and spending a lot of my time studying, there. If you're interested in improving pyp2rpm, I'll make every effort to be available to review PRs and offer any help that I can.
Could you change the list in #216 (comment) into the checklist so we can see the status of individual subtasks?
Sure, though for the most part there are open issues for things that need to be done.
We should make sure there's a license for each of the modules we already include
Just to clarify: we are talking about the License line in setup() command (or its setup.cfg or pyproject.toml equivalent) right? We actually don’t need to include the physical LICENSE.txt in each package.
Just to clarify: we are talking about the License line in
setup()command (or itssetup.cfgorpyproject.tomlequivalent) right? We actually don’t need to include the physicalLICENSE.txtin each package.
That part is already done here, right?
Line 46 in 6ab5058
Line 46 in 6ab5058
I think that line item means that pyp2rpm should check that each new package has such line pointing to free license (probably by checking it against https://spdx.org/licenses/).
Ah yes, and it would also be great if there was a spdx2fedora() conversion.
Ah yes, and it would also be great if there was a
spdx2fedora()conversion.
/me quietly snickers, because some other distros (e.g., I work for SUSE) just use SPDX abbreviations.
Ah yes, and it would also be great if there was a
spdx2fedora()conversion./me quietly snickers, because some other distros (e.g., I work for SUSE) just use SPDX abbreviations.
Good for you!
Ah yes, and it would also be great if there was a
spdx2fedora()conversion.
We actually have this functionality. rust2rpm and go2rpm use it:
https://pagure.io/fedora-rust/rust2rpm/blob/main/f/rust2rpm/licensing.py
@gordonmessmer do you still need help? I'm using pyp2rpm a lot lately and I would gladly to help with some pain points, specially for el8 and el9
I think nowadays, this package can be greatly simplified and do something similar rust2rpm i.e. create a spec file from a simple jinja template. Can try out the following template (shamelessly adapted from rust2rpm):
# Generated by pyp2rpm 4
%bcond_without check
%global pypi {{ name }}
Name: python-{{ name }}
Version: {{ version }}
Release: %autorelease
Summary: {{ summary }}
License: {{ license }}
URL: {{ url|default("https://pypi.org/project/{}".format(name)) }}
Source: %{pypi_source {{ name }}}
{%- if noarch -%}
BuildArch: noarch
{%- endif -%}
BuildRequires: python3-devel
%global _description %{expand:
{{ description|filter_to_split_max_characters() }}}
%description %{_description}
%package -n python3-{{ name }}
Summary: %{summary}
%description -n python3-{{ name }} %_description
{%- if subpkg -%}
%pyproject_extras_subpkg -n python3-{{ name }} {{ subpkg|join(",") }}
{%- endif -%}
%prep
%autosetup -n {{ name }}-%{version}
%generate_buildrequires
%pyproject_buildrequires -x {{ extras }}
%build
%pyproject_wheel
%install
%pyproject_install
%pyproject_save_files {{ install_modules }}
%if %{with check}
%check
%pytest
%endif
%files -n python3-{{ name }} -f %{pyproject_files}
%changelog
%autochangelogAll of the data being extracted from the sdist PKG-INFO. This is a very minimalistic template so that it is still readable for the general structure. For a more comprehensive template we should consult rust2rpm approach 1.
The tricky part would be handling %pyproject_save_files, but for now even having it required to be manually specified would help a lot.
Footnotes
@LecrisUT That is pretty much what https://github.com/befeleme/pyp2spec is doing
@hroncok great pointer. I've given it a try and looked at the template, and it works good for creating an initial spec file. But there are a few notes on the comparison with rust2rpm
- There are already
rust2rpm,go2rpm. It would be nice to have some consistency and have thepython/pypbe also2rpminstead of2spec - The workflow of
pyp2specis not exactly similar, in that case the.conffile is always re-generated, while withrust2rpm, it always reads the.tomlfile for fields to override.conf2specis similar in behavior, but in that case the version has to be updated on the.confside, instead of passing it to the cli - The template is written not in a form that can be constantly reused, e.g. hard-coded comments
The reason why I point out this issues is because with rust2rpm, I have written a packit workflow to make use of it and automatically update based on the .toml files, e.g.:
packit.yaml
specfile_path: .distro/rust-atuin.spec
upstream_package_name: atuin
downstream_package_name: rust-atuin
files_to_sync:
- src: .distro/
dest: ./
delete: true
filters:
- "protect .git*"
- "protect sources"
actions:
fix-spec-file:
- sh -c 'rust2rpm atuin ${PACKIT_PROJECT_VERSION}'
create-archive:
- sh -c 'spectool -g -s0 .distro/rust-atuin.spec'
- sh -c 'echo atuin-${PACKIT_PROJECT_VERSION}.crate'
srpm_build_deps:
- rust2rpm
jobs:
- job: copr_build
trigger: commit
targets:
- fedora-rawhide
- job: propose_downstream
trigger: release
dist_git_branches:
- fedora-rawhide
- job: koji_build
trigger: commit
dist_git_branches:
- fedora-all
- job: bodhi_update
trigger: commit
dist_git_branches:
- fedora-branchedI haven't tested for pull_from_upstream, but in principle it should work equivalently, but with different sources for version. It would be nice to have equivalents for all variants