Running "sudo dnf install python3-twine" doesn't currently get you a "twine" command - it only gets you versioned twine-3 and twine-3.6 commands, with the unversioned file living in python2-twine. This isn't right, as twine isn't intended for use as a Python library, it's a PyPI CLI application. This means there should only be a single "python-twine" RPM that installs a "twine" command running in the default system Python version.
Yeeeeah, this was one of my early packages and it's not very good. It seems to me it should probably just be called "twine", in addition to all the things you noted. I don't see anything specific in the guidelines, though. Thoughts?
Yep, that would make sense - I had to make exactly the same change for fedmod [1] after realising the auto-generated spec from pyp2rpm was designed for Python libraries and frameworks, not command line tools that happened to be implemented in Python. However, it's a more annoying change to make, and the current SRPM name isn't actually *wrong* (since the python- prefix correctly implies that PyPI is twine's main upstream publication channel) So the changes definitely needed are: * RPM name -> twine (obsoleting both python2-twine and python3-twine) * no versioned binaries * builds for the default system Python only Whether or not to chang the SRPM name as well would be up to you - I'll note that one concrete advantage of the current name is that it makes it easier for automated tools to correlate the system package with the upstream project. [1] https://pagure.io/modularity/fedmod/issue/27
I opted to leave the SRPM name the same, but the RPM is now just "twine". Fixed in python-twine-1.9.1-3.fc28
Thank you!