Bug 1194545
Summary: | Review Request: python-cached_property - A cached-property for decorating methods in Python classes. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pete Travis <me> |
Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | awilliam, package-review |
Target Milestone: | --- | Flags: | adamw+fedora:
fedora-review+
gwync: fedora-cvs+ |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | python-cached_property-1.0.0-4.fc22 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-04-17 18:15:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1194428 |
Description
Pete Travis
2015-02-20 06:45:20 UTC
you don't need to define sitearch, and it's 'good practice' to make sitelib/sitearch definition conditional on old EL and version specific: %if 0%{?rhel} && 0%{?rhel} <= 6 %{!?python2_sitelib: %global python2_sitelib %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")} %endif then use python2_sitelib not python_sitelib (this is all from https://fedoraproject.org/wiki/Packaging:Python ). The packaging guidelines require using commit-based tarballs when using github-generated sources, not versions: https://fedoraproject.org/wiki/Packaging:SourceURL#Github that can be a bit tricky to read, but yes, it really does mean you should use a tarball derived from a commit hash even for stable releases, unless upstream provides tarballs in some way *other* than github's generation system. The justification is that commit hashes are less mutable and thus more predictable, so we should take advantage of that when we can. You can still version the package as 1.0.0-1 , but the Source0 URL should use a commit hash. See http://pkgs.fedoraproject.org/cgit/php-google-apiclient.git/tree/php-google-apiclient.spec for an example. Thanks for the thorough explanation, Adam. I've made the suggested changes, and a few more minor ones after reviewing rpmlint and the python guidelines again. Were you envisioning this package in EPEL, or is the conditional only for best practices? Also, I'm wavering on the package name - "python-cached-property" to match the upstream project, or "python-cached_property" to match the module. Leaning towards the latter - any thoughts? I find the guidelines wonderfully unhelpful on the topic: "When naming packages for Fedora, the maintainer must use the dash '-' as the delimiter for name parts. The maintainer must NOT use an underscore '_', a plus '+', or a period '.' as a delimiter." But: "packages where the upstream name naturally contains an underscore are excluded from this." and the Python section says: "Packages of python modules (thus they rely on python as a parent) use a slightly different naming scheme. They should take into account the upstream name of the python module. This makes a package name format of python-$NAME. When in doubt, use the name of the module that you type to import it in a script." it also says: "When a module has a dot in its name, the usual rule about changing "." to "-" applies." (with 'usual rule' as a link to the Separators section), but does *not* say anything about changing _ to -. So....??? I recommend asking devel@. :P After some thought, I'm going to go with matching the name of the module, following the spirit of the Python naming guidelines, which specify matching the module and don't mention the upstream project name. I'll update the SRPM soon, or on the next bump if you see more room for improvement. Spec URL: https://immanetize.fedorapeople.org/python-cached_property.spec SRPM URL: https://immanetize.fedorapeople.org/python-cached_property-1.0.0-2.fc23.src.rpm * Fri Mar 13 2015 Pete Travis <me> - 1.0.0-2 - Use the module name for the package name. * Fri Feb 20 2015 Pete Travis <me> 1.0.0-1 - Initial packaging. Looks fine. I'm not sure what the Party Line is on whether we're supposed to make 'python-foo' the py3 version and have a 'python2-foo' these days, or vice versa, or have just 'python2-foo' and 'python3-foo' and have a virtual Provides: for 'python-foo' which we can switch over at will; but I don't think that needs to block the review. [adamw@adam SRPMS]$ rpmlint python-cached_property-1.0.0-2.fc23.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [adamw@adam SRPMS]$ rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/python-cached_property-1.0.0-2.fc23.noarch.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [adamw@adam SRPMS]$ rpmlint python-cached_property-1.0.0-2.fc23.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [adamw@adam SRPMS]$ rpmlint ../SPECS/python-cached_property.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. All must-have items on the review checklist pass => APPROVED. Thanks, Adam. IMO the only sane way to make python-foo be the py3 version would be for *all* python packages to follow this convention; we'll know for sure that day has come when the mass bug filing comes :) New Package SCM Request ======================= Package Name: python-cached_property Short Description: A cached-property for decorating methods in Python classes. Upstream URL: https://github.com/pydanny/cached-property Owners: immanetize adamwill Branches: f22 f21 InitialCC: New Package SCM Request ======================= Package Name: python-cached_property Short Description: A cached-property for decorating methods in Python classes. Upstream URL: https://github.com/pydanny/cached-property Owners: immanetize adamwill Branches: f22 f21 epel6 epel7 InitialCC: Git done (by process-git-requests). python-cached_property-1.0.0-4.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/python-cached_property-1.0.0-4.fc22 python-cached_property-1.0.0-4.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/python-cached_property-1.0.0-4.fc21 python-cached_property-1.0.0-4.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/python-cached_property-1.0.0-4.el7 python-cached_property-1.0.0-4.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/python-cached_property-1.0.0-4.el6 python-cached_property-1.0.0-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/python-cached_property-1.0.0-4.fc20 Package python-cached_property-1.0.0-4.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing python-cached_property-1.0.0-4.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1434/python-cached_property-1.0.0-4.el6 then log in and leave karma (feedback). python-cached_property-1.0.0-4.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. python-cached_property-1.0.0-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. python-cached_property-1.0.0-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. python-cached_property-1.0.0-4.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. python-cached_property-1.0.0-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. |