Bug 644708

*** Bug 605413 has been marked as a duplicate of this bug. ***

Just some comments for now:

- There was a guidelines change, so you are not allowed to disable the internal
dependency generator (cvisualmodule is even not inside of this package ;-), but
it's:
pymongo.x86_64: W: private-shared-object-provides
/usr/lib64/python2.7/site-packages/pymongo/_cmessage.so _cmessage.so()(64bit)
pymongo-gridfs.x86_64: W: no-documentation
python-bson.x86_64: W: private-shared-object-provides
/usr/lib64/python2.7/site-packages/bson/_cbson.so _cbson.so()(64bit)

- python-bson doesn't require the main package and contains no license. Either
include the appropriate license or require the main package.
  (didn't check for license issues yet)

- This package cleanly compiles with python3, could you enable python3
subpackages?
  See: https://fedoraproject.org/wiki/Packaging:Python#Example_spec_file
  (you need to run 2to3 --nobackups --write %{py3dir} thought)

- maybe you want to run nosetests and add a %check section...
  I don't know the internals of pymongo, but right now most tests are failing,
so are you sure this package will work, once imported?

(In reply to comment #2)
> - There was a guidelines change, so you are not allowed to disable the internal
> dependency generator (cvisualmodule is even not inside of this package ;-), but
> it's:
> pymongo.x86_64: W: private-shared-object-provides
> /usr/lib64/python2.7/site-packages/pymongo/_cmessage.so _cmessage.so()(64bit)
> pymongo-gridfs.x86_64: W: no-documentation
> python-bson.x86_64: W: private-shared-object-provides
> /usr/lib64/python2.7/site-packages/bson/_cbson.so _cbson.so()(64bit)

Forgot to add a link here:
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering

This works:
%{?filter_setup:
%filter_provides_in %{python_sitearch}.*\.so$
%filter_setup
}

SRPM:
http://github.com/downloads/silas/rpms/pymongo-1.9-2.fc13.src.rpm

(In reply to comment #2)
> Just some comments for now:
> 
> - There was a guidelines change, so you are not allowed to disable the internal
> dependency generator (cvisualmodule is even not inside of this package ;-), but
> it's:
> pymongo.x86_64: W: private-shared-object-provides
> /usr/lib64/python2.7/site-packages/pymongo/_cmessage.so _cmessage.so()(64bit)
> pymongo-gridfs.x86_64: W: no-documentation
> python-bson.x86_64: W: private-shared-object-provides
> /usr/lib64/python2.7/site-packages/bson/_cbson.so _cbson.so()(64bit)

This should be fixed.

> - python-bson doesn't require the main package and contains no license. Either
> include the appropriate license or require the main package.
>   (didn't check for license issues yet)

I added the license to the subpackage.

> - This package cleanly compiles with python3, could you enable python3
> subpackages?
>   See: https://fedoraproject.org/wiki/Packaging:Python#Example_spec_file
>   (you need to run 2to3 --nobackups --write %{py3dir} thought)

The package compiles without error but doesn't actually work. I added the code so its easy to try at a later point, but without the python-nose package supporting python3 I wouldn't be comfortable enabling a database driver with auto-magic code conversion (esp one with lots of C code).

That said, if someone else is interested in maintaing a patch for the pymongo code and all the tests (they import nose) I might be willing to include it.

Upstream has a ticket for python3 support: http://jira.mongodb.org/browse/PYTHON-84

> - maybe you want to run nosetests and add a %check section...
>   I don't know the internals of pymongo, but right now most tests are failing,
> so are you sure this package will work, once imported?

A bunch of the tests require an active MongoDB connection, I've created a check section that excludes those tests (anything that imported get_connection) and should at least pass now.

(In reply to comment #4)
> (In reply to comment #2)
> > Just some comments for now:
> > 
> > pymongo.x86_64: W: private-shared-object-provides
> > /usr/lib64/python2.7/site-packages/pymongo/_cmessage.so _cmessage.so()(64bit)
> > pymongo-gridfs.x86_64: W: no-documentation
> > python-bson.x86_64: W: private-shared-object-provides
> > /usr/lib64/python2.7/site-packages/bson/_cbson.so _cbson.so()(64bit)
> 
> This should be fixed.
It is.
> > - python-bson doesn't require the main package and contains no license. Either
> > include the appropriate license or require the main package.
> >   (didn't check for license issues yet)
> 
> I added the license to the subpackage.
Ok
> Upstream has a ticket for python3 support:
> http://jira.mongodb.org/browse/PYTHON-84

Sure, didn't check for upstream if it's already supported to be honest...

> > - maybe you want to run nosetests and add a %check section...
> >   I don't know the internals of pymongo, but right now most tests are failing,
> > so are you sure this package will work, once imported?
> 
> A bunch of the tests require an active MongoDB connection, I've created a check
> section that excludes those tests (anything that imported get_connection) and
> should at least pass now.
Now:
"""
Ran 0 tests in 0.453s

OK
"""
;-)

It would be nice, if an active MongoDB connection can be hacked together somehow, so there is a testsuite to check (I know nothing about the internalls if that's possible or not...).

-> NICE–TO–HAVE (not even a SHOULD^^)

- Isn't the license ASL 2.0 and MIT?
  See bson/time64*

- BR might be wrong:
  It would be better to use python2-devel, don't know if python-devel could become python3-devel, when changing the default /usr/bin/python etc...

Rest looks ok.

SRPM:
http://github.com/downloads/silas/rpms/pymongo-1.9-3.fc13.src.rpm

(In reply to comment #5)
> Now:
> """
> Ran 0 tests in 0.453s
> 
> OK
> """
> ;-)

Yeah, missed that, fixed now.

> It would be nice, if an active MongoDB connection can be hacked together
> somehow, so there is a testsuite to check (I know nothing about the internalls
> if that's possible or not...).

Not really, no.

> -> NICE–TO–HAVE (not even a SHOULD^^)
> 
> - Isn't the license ASL 2.0 and MIT?
>   See bson/time64*

Fixed.

> - BR might be wrong:
>   It would be better to use python2-devel, don't know if python-devel could
> become python3-devel, when changing the default /usr/bin/python etc...

Updated it.

One last thing:
https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios
"""
In addition, the package must contain a comment explaining the multiple licensing breakdown. The actual implementation of this is left to the maintainer. [...]
"""

Please fix that too, before importing.
Thanks
______________________________________________________________________________
|               |
|    APPROVED   |
|_______________|

Added comment about licensing.

SRPM:
http://github.com/downloads/silas/rpms/pymongo-1.9-4.fc13.src.rpm

New Package CVS Request
=======================
Package Name: pymongo
Short Description: Python driver for MongoDB
Owners: silas
Branches: F-13 F-14 EL-5 EL-6
InitialCC:

Git done (by process-git-requests).

pymongo-1.9-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/pymongo-1.9-4.fc14

pymongo-1.9-4.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/pymongo-1.9-4.fc13

pymongo-1.9-8.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/pymongo-1.9-8.el5

pymongo-1.9-4.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pymongo'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/pymongo-1.9-4.fc14

pymongo-1.9-4.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

pymongo-1.9-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

pymongo-1.9-8.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.