Bug 1244514 - Review Request: python-snappy - Python library for the snappy compression library from Google
Summary: Review Request: python-snappy - Python library for the snappy compression lib...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1244522
TreeView+ depends on / blocked
 
Reported: 2015-07-19 14:06 UTC by Julien Enselme
Modified: 2015-08-10 10:12 UTC (History)
3 users (show)

Fixed In Version: python-snappy-0.5-3.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-10 10:07:28 UTC
Type: ---
zbyszek: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Julien Enselme 2015-07-19 14:06:37 UTC
Spec URL: http://jenselme.perso.centrale-marseille.fr/visible/SPECS/python-snappy.spec
SRPM URL: http://jenselme.perso.centrale-marseille.fr/visible/SRPMS/python-snappy-0.5-1.fc22.src.rpm
Description:
Python bindings for the snappy compression library from Google.

Fedora Account System Username:

Comment 1 Christopher Meng 2015-07-19 14:28:41 UTC
I'm not sure if it should be snappy-python or python-snappy, one day in a future if someone is trying to package the real snappy on pypi:

https://pypi.python.org/pypi/snappy

Comment 3 Julien Enselme 2015-07-19 15:58:46 UTC
Since the pypi name of my package is python-snappy, maybe should I rename it python-python-snappy?

The name would be a bit strange but it would reflect the true name of the software and would avoid name collision with the real snappy.

Comment 4 Michael Schwendt 2015-07-19 16:35:00 UTC
> the real snappy

Blasphemy! =:-) *g*

http://pkgs.fedoraproject.org/cgit/?q=snappy
http://pkgs.fedoraproject.org/cgit/snappy.git/tree/


> https://pypi.python.org/pypi/snappy

"SnapPy is a program …" and not only a Python Module. Hence it would not be subject to Fedora's naming guidelines for Python modules.

Still it would conflict with the existing "snappy" package.

https://fedoraproject.org/wiki/Packaging:Conflicts#Conflicting_Package_Names


> python-python-snappy

Asking on packaging@ list could be an idea. If there were a 2nd python-snappy package (and python3-snappy, too), I'd favour a naming like python-snappy-bindings

Comment 5 Zbigniew Jędrzejewski-Szmek 2015-07-22 00:50:26 UTC
I think that ship has sailed... and snappy the compressor will always be vastly more recognizable than snappy the manifold mangler. So I'd vote for python-snappy for this package, and snappy-geometry for the hypothetical other package.

Is using %{py3dir} necessary?

Comment 7 Julien Enselme 2015-07-24 07:03:31 UTC
> %py3dir usage has been removed from the packaging guidelines anyway:

I guess I missed that. I corrected the package accordingly and added CFLAGS in %%build.

Considering that

> "SnapPy is a program …" and not only a Python Module.  Hence it would not be subject to Fedora's naming guidelines for Python modules.

and 

> So I'd vote for python-snappy for this package, and snappy-geometry for the hypothetical other package.

and no real answer on https://lists.fedoraproject.org/pipermail/packaging/2015-July/010850.html, I will leave this package name as is. Is it good for you?

SPEC: http://jenselme.perso.centrale-marseille.fr/visible/SPECS/python-snappy.spec
SRPM: http://jenselme.perso.centrale-marseille.fr/visible/SRPMS/python-snappy-0.5-2.fc22.src.rpm

Comment 8 Michael Schwendt 2015-07-24 10:07:54 UTC
> and no real answer

That's not the point of mailing packaging@ list.

If nobody has strong feelings about it, that is much better input than not having asked at all. The packaging@ list is still advertised on the FPC's page: https://fedoraproject.org/wiki/Packaging_Committee#Discussions

Solving name conflicts can be very hard, especially if upstream is not willing to help in any way:
  https://fedoraproject.org/wiki/Packaging:Conflicts#Approaching_Upstream

While it may be trivial to choose a different _package name_, a future package may include files that conflict. Then the real fun will start. Just imagine conflicting executables, Python module paths or shared libs.


> snappy + python-snappy

"First come, first served" is quite common when naming packages. I don't see any benefit in renaming "python-snappy" to something like "python-python-snappy" without knowing the details how that would avoid any conflict with stuff from the "SnapPy" project.

Comment 9 Julien Enselme 2015-07-24 10:38:15 UTC
>> and no real answer

> That's not the point of mailing packaging@ list.

I didn't express myself clearly: I understood that if nobody has strong feeling about it I won't have a strong answer on how to name this package. Thanks anyway for the complement of information.

Comment 10 Zbigniew Jędrzejewski-Szmek 2015-07-30 15:07:31 UTC
Add Provides python2-snappy = %{version}-%{release}.

Putting _snappy in the global namespace is an abomination. Somebody should hit upstream with a cluebat.

You changed %{py3dir} to python2 and python3 dirs. This is better, but best would be getting of the dirs completely. This will follow the new draft guidelines that are being worked on, so you'll be ready for the future :)
So I'd strongly suggest removing all the copying and push/popd-ing.

Also consider adding %global _docdir_fmt %{name}. No need for duplicate dirs with the same contents.

Looks good. The only required change would be the added provides, the other two are suggestions. Either way, please post a new version so that I can ack it.

Comment 11 Julien Enselme 2015-07-30 21:09:07 UTC
- Issue about _snappy in global namespace signaled: https://github.com/andrix/python-snappy/issues/33
- Remove python2 and python3 dirs
- Add Provides:       python2-snappy = %{version}-%{release}

Comment 13 Zbigniew Jędrzejewski-Szmek 2015-07-31 02:33:03 UTC
- package name is OK (comment #c8)
- license is OK (BSD)
- license file is not present but upstream is notified
- spec file is nice and simple
- fs layout is OK
- rpmlint says "4 packages and 0 specfiles checked; 0 errors, 0 warnings."
- provides and requires as OK
- module seems to work as expected under both python versions

Package is APPROVED.

Comment 14 Julien Enselme 2015-07-31 08:57:50 UTC
Thanks for the review, I will update the spec to follow the new guideline once it is officially announced.

New Package SCM Request
=======================
Package Name: python-snappy
Short Description: Python library for the snappy compression library from Google
Upstream URL: https://pypi.python.org/pypi/python-snappy
Owners: jujens
Branches: f22 f23
InitialCC:

Comment 15 Gwyn Ciesla 2015-07-31 13:27:59 UTC
Git done (by process-git-requests).

Comment 16 Fedora Update System 2015-07-31 15:16:55 UTC
python-snappy-0.5-3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/python-snappy-0.5-3.fc22

Comment 17 Fedora Update System 2015-07-31 15:37:54 UTC
python-snappy-0.5-3.fc23 has been submitted as an update for Fedora 23.
https://admin.fedoraproject.org/updates/python-snappy-0.5-3.fc23

Comment 18 Fedora Update System 2015-07-31 16:49:03 UTC
python-snappy-0.5-3.fc23 has been pushed to the Fedora 23 testing repository.

Comment 19 Fedora Update System 2015-08-10 10:07:28 UTC
python-snappy-0.5-3.fc22 has been pushed to the Fedora 22 stable repository.

Comment 20 Fedora Update System 2015-08-10 10:12:16 UTC
python-snappy-0.5-3.fc23 has been pushed to the Fedora 23 stable repository.


Note You need to log in before you can comment on or make changes to this bug.