Initial build in my autorpm repo: https://copr.fedorainfracloud.org/coprs/ncoghlan/autorpm/build/656312/
Need to check that works properly, and look at moving it to a shared COPR account rather than my personal one.
@langdon @asamalik Do we have an existing org in Fedora's COPR for pre-release modularity tooling?
Also, is supporting F26+ enough, or do we need to work out a way to get this working on EPEL 7 as well? While I can get rid of the dnf dependency (and plan to do that anyway for speed reasons), libsolv is a hard requirement in order to work effectively with the dependency metadata (and I'd really prefer to continue relying on Python 3.6+ features like f-strings).
Dedicated COPR here: https://copr.fedorainfracloud.org/coprs/g/modularity/fedmod/
I currently have builds set up for F26, F27, and Rawhide, for both x86_64 and ppc64le, building directly from the PyPI sdist, with automatic rebuilds based on Anitya messages configured.
Alas, it turns out Fedora 26 still only has requests 2.13 (from January), and that's missing a 2.18 feature (from June) that fedmod is currently using (native context management support).
requests 2.13
In order to test that scenario without running through multiple COPR update cycles, I'll add an environmental configuration to tox that allows testing purely against system packages (i.e. requests, lxml, click, etc, will all need to come from their system packages, not from PyPI), such that testing that environment on Fedora 26 indicates whether or not we can expect the F26 RPM to work properly.
The other major problem with the initial packages is that pyp2rpm assumes PyPI packages are Python libraries by default, and hence configures them for dual stack Python 2/3 support.
pyp2rpm
That isn't actually what we want for fedmod, so I'll need to go in and replace the generated spec file with one that abides by the guidlines in https://fedoraproject.org/wiki/Packaging:Python#Executables_in_.2Fusr.2Fbin (i.e. only installs /usr/bin/fedmod).
I also want to change the RPM name to just be "fedmod", and it would probably make sense to change the SRPM name to fedmod as well (the fact it's written in Python should be an implementation detail, and the support module name is "_fedmod" to help reflect that)
Merged https://pagure.io/modularity/fedmod/pull-request/25 to fix the F26 compatibility problem.
The fedmod 0.0.5 release installs and runs from COPR on F26!: https://pagure.io/modularity/fedmod/c/6a6a428ff35abed9c75f17bdd44d3736a3f6e567?branch=master
Not closing yet, as there should be a section on tagging and pushing releases added to the README first.
Release docs added in https://pagure.io/modularity/fedmod/pull-request/46
Metadata Update from @ncoghlan: - Issue close_status updated to: RESOLVED - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.