Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Diego M. Rodriguez]

Hello Gianfranco,

>
> a ping when the other package is renamed and in testing even better.
>

I'm finally making effective the ping, as the long-standing naming
conflict has been solved on the latest "jellyfish" version (2.2.6-1) [1]
(which entered testing on 2016-09-06) by the renaming of its binary
package to "python3-dna-jellyfish", thanks to the efforts by Andreas
Tille.

I have also moved development to Alioth [2] in order to conform to the
DPMT procedures, and also built the package from that repository and
uploaded a new version to mentors [3].

Thanks again for your patience and your time,

[1] https://packages.qa.debian.org/j/jellyfish.html
[2] 
https://anonscm.debian.org/cgit/python-modules/packages/python-jellyfish.git/
[3] https://mentors.debian.net/package/python-jellyfish

-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Diego M. Rodriguez]

control: block -1 by 819016

Hello Giafranco,

> FWIW adding "u" to the strings indeed fixed the issue
> e.g. 'string' becomes u'string' (IIRC forcing unicode)

thanks, it's been confirmed by upstream and promptly fixed on the
upstream repository [1].

> BTW, the Python policy is something like
> "python-foo" means "import foo" works.
> Adding str migth deviate from the policy, you might want to ask #-python
> about this specific issue (and quote the conversation here)

thanks for letting me know about the potential Policy issue with the
package name. After discussing it at #debian-python [2], it seems that
the deviation would be acceptable, however it was suggested that the
conflicts as a whole would be better solved by renaming the *existing*
package:

 there are 2 reported installations of python3-jellyfish on popcon - I'd 
rename the other python3-jellyfish now (module and binary package) and a then 
upload yours with python3-jellyfish name

> thanks, I'll wait for your action,

I have commented on #819016 in the hopes of discussing the new approach
with the maintainer of the existing jellyfish package, and I'll ping
you back once the situation is sorted out.

Again, thanks a lot,

[1] https://github.com/jamesturk/jellyfish/issues/51
[2] http://paste.debian.net/432489
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Gianfranco Costamagna]

control: tags -1 moreinfo

Hi

>I'm quite certain that it is indeed a problem with the README (the

>library was initially only available on Python 2, and the README.rst has
>not gone through significant changes since then, even if Python 3
>support was introduced around 0.3.2). I'll follow up on upstream,
>hopefully resulting in a quick fix indeed.


FWIW adding "u" to the strings indeed fixed the issue
e.g. 'string' becomes u'string' (IIRC forcing unicode)
>My apologies if I should have explicitely mentioned it earlier: the
>conflicts with the existing "jellyfish" Debian package were noticed
>earlier on [1], and a recent discussion on the ITP bug [2] resulted on
>an agreement with the jellyfish maintainer that basically should result
>in:
>- the *existing* python-jellyfish should have its python module name
>renamed (work in progress at [3]).
>- this package should indeed be renamed to something else (
>"python-jellyfishstr" being the most likely candidate), and keep the
>python "jellyfish" module name.>
>
>I was waiting on #819016 being closed before making the changes to this
>package (renaming + uploading to the debian-python git + adding the VCS
>control fields) - again, sorry if it should have been stated more
>clearly that the package was not ready for uploading yet due to the
>naming/module conflicts.
>
>I'd be happy to proceed with the renaming right away, if that's ok - in
>regards to the BTS, would it be preferable to use the control tags
>(reopen, retitle, block on #819016?) or just submit a new ITP+RFS

>entirely?

block -1 by nnn is fine.



a ping when the other package is renamed and in testing even better.

BTW, the Python policy is something like
"python-foo" means "import foo" works.
Adding str migth deviate from the policy, you might want to ask #-python
about this specific issue (and quote the conversation here)

thanks, I'll wait for your action,

Gianfranco

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Diego M. Rodriguez]

Thanks Paul and Gianfranco for your clarification in regards to the
style patches, I was confused by the mention of the check-all-things
commands on your initial reply and I appreciate your explanation!

> Just a question:
> the code in README file, works for python3 but not for python.
> However I think its a README fault, not a code fault.

I'm quite certain that it is indeed a problem with the README (the
library was initially only available on Python 2, and the README.rst has
not gone through significant changes since then, even if Python 3
support was introduced around 0.3.2). I'll follow up on upstream,
hopefully resulting in a quick fix indeed.

> I changed the target to unstable, bumped std-version to 3.9.8 (it got bumped
> after my previous review), and uploaded on unstable.
...
> https://packages.debian.org/sid/python3-jellyfishoops
> 
> so you have to rename/move it.

My apologies if I should have explicitely mentioned it earlier: the
conflicts with the existing "jellyfish" Debian package were noticed
earlier on [1], and a recent discussion on the ITP bug [2] resulted on
an agreement with the jellyfish maintainer that basically should result
in:
- the *existing* python-jellyfish should have its python module name
renamed (work in progress at [3]).
- this package should indeed be renamed to something else (
"python-jellyfishstr" being the most likely candidate), and keep the
python "jellyfish" module name.

I was waiting on #819016 being closed before making the changes to this
package (renaming + uploading to the debian-python git + adding the VCS
control fields) - again, sorry if it should have been stated more
clearly that the package was not ready for uploading yet due to the
naming/module conflicts.

I'd be happy to proceed with the renaming right away, if that's ok - in
regards to the BTS, would it be preferable to use the control tags
(reopen, retitle, block on #819016?) or just submit a new ITP+RFS
entirely?

Best regards, and thanks again,

[1] https://lists.debian.org/debian-python/2016/01/msg1.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#54
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819016

-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Paul Wise]

On Thu, Apr 7, 2016 at 1:57 AM, Diego M. Rodriguez wrote:

> On my earlier attempts (<=0.5.1-1) I did include some patches that were
> aimed towards fixing pep8/flake8 warnings, although I dropped them on
> the 0.5.3 package. The reason was that upstream has expressed his
> willingness to ignore E501 and E226 [2], and after a brief discussion at
> #debian-python I was under the impression that I should "patch it only
> if you must, pep8 is not a must", favouring closeness to upstream over
> style fixes.
>
> I'm wondering if you could provide a definitive answer on whether to
> patch or not patch those issues, as I'm a bit unsure and I'd be happy
> to proceed with either solution.

pep8 is solely checking against the PEP-8 Python style guide. It is
not in any way useful to have Debian patches for changing the style.
cats only runs pep8 so people ask upstream to make their code more
readable via PEP-8, but the style used by upstream is completely up to
them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Diego M. Rodriguez]

Thanks for the review, Gianfranco. I have just uploaded a new version of
the package to mentors [1] that fixes some of the issues, although I'd
appreciate some further clarification or guidance on a few others:

> $ codespell --quiet-level=3
> 
> $ pyflakes .
> 
> $ pyflakes3 .
> 
> $ pep8 --ignore W191 .

On my earlier attempts (<=0.5.1-1) I did include some patches that were
aimed towards fixing pep8/flake8 warnings, although I dropped them on
the 0.5.3 package. The reason was that upstream has expressed his
willingness to ignore E501 and E226 [2], and after a brief discussion at
#debian-python I was under the impression that I should "patch it only
if you must, pep8 is not a must", favouring closeness to upstream over
style fixes.

I'm wondering if you could provide a definitive answer on whether to
patch or not patch those issues, as I'm a bit unsure and I'd be happy
to proceed with either solution.

> one license seems missing
> ./.run_with_env.cmd::: License: CC0 1.0 Universal: 
> http://creativecommons.org/publicdomain/zero/1.0/

This might be related to the github vs pypi issue raised by Víctor on
a previous comment: the PyPI package [3] does not seem to contain the
aforementioned file, but the github release does.

The intent was to use the PyPI packages during the building process
(specially after 0.5.3, as they now include the docs/ and test/ files)
as declared in debian/watch, although I left references to the github
repository in debian/control (Homepage:) and debian/copyright (Source)
as I felt they better reflected the "official" homepage of the package.

> please run wrap-and-sort

Done.

> std-version is 3.9.7

Done.

> python-all (>= 2.6.6-3~),
> this seems satisfied even in oldstable

This is basically a result of following the Python Library Style Guide
at [4], and feels rather conservative indeed. I'm not sure if you are
suggesting dropping the version specification entirely, or any other
measures?
 
> isn't sphinx a build-depends-indep?

This was also a result of following [4] - although in this case sphinx
it is only used for building the documentation package indeed. As a
result, I have moved sphinx and python-docutils to build-depends-indep
as you suggested.

Again, thanks a lot for the review! 

[1] https://mentors.debian.net/package/python-jellyfish
[2] https://github.com/jamesturk/jellyfish/pull/50
[3] https://pypi.python.org/pypi/jellyfish/0.5.3
[4] https://wiki.debian.org/Python/LibraryStyleGuide#Build-Depends
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi, lets review
check-all-the-things:

$ codespell --quiet-level=3

$ pyflakes .

$ pyflakes3 .

$ pep8 --ignore W191 .

one license seems missing
./.run_with_env.cmd::: License: CC0 1.0 Universal: 
http://creativecommons.org/publicdomain/zero/1.0/


please run wrap-and-sort
std-version is 3.9.7
python-all (>= 2.6.6-3~),
this seems satisfied even in oldstable

isn't sphinx a build-depends-indep?

the other stuff looks good, and sorry if something has already been pointed out.




cheers,


G.

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Diego M. Rodriguez]

Thanks a lot for the feedback and help, Víctor!

> # d/patch
> 
> Please upstream them (in case they aren't already in 0.5.2).
> ...
> # lintian
> 
> there's a spelling error in manpage: accomodate accommodate (upstream
> the fix).

I have forwarded both those issues upstream [1], which combined with
your pull request will hopefully result in being able to use the
tarball directly and indeed remove the extra complexity caused by the
use of git submodules once a new version is released.

I'll work on the remaining issues (debian/control, debian/copyright) in
the meantime, and once the new version is released will make sure that
all references to the github repository are removed in favour of the
PyPi tarball, and get everything ready for a final cleanup.

[1] https://github.com/jamesturk/jellyfish/pull/50

-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Víctor Cuadrado Juan]

About gbp.conf, we at #debian-mentors have realized that if you want to
comply with DPMT's Policy, then you will need to set up the `upstream`
branch by importing only the tar.gzs, without upstream's commit history
on it.

That makes gbp.conf superfluous and also there's no need to think about
upstream submodules.


-- 
Víctor Cuadrado juan

E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Víctor Cuadrado Juan]

I can't sponsor you (I'm just a contributor) but since I packaged
python-jellyfish on my own as I didn't see your ITP first, let me
chime in to be of some help.


# d/watch
It is correct, but from the contents of the orig.tar.gz I see you
have used the one from Github (that contains the docs/ etc) and not
the one from PyPi. Since that's the one you are advertising, in the
future please take the PyPi one (or rework the watch file).

(I have opened an issue[1] to make upstream include the docs/ on the
tar.gz).


# d/changelog

Upstream has a published 0.5.2, please package it :).


# d/control

Personal preference: indent and comment which are needed for tests,
such as here[2].


# d/patch

Please upstream them (in case they aren't already in 0.5.2).


# d/copyright

It's missing:

```
Files: jellyfish/test.py
Copyright: 2015 James Turk
   2010 Michael Stephens
License: BSD-2-clause

Files: setup.py
Copyright: 2015 James Turk
   2010 Michael Stephens
   2012 Petr Hosek
License: BSD-2-clause

Files:
 cjellyfish/mra.c
 cjellyfish/damerau_levenshtein.c
Copyright: 2015 James Turk
   2013 Danrich Parrol
License: BSD-2-clause

Files: cjellyfish/porter.c
Copyright: 2015 Martin Porter
License: BSD-2-clause
Comment:
 The original author licenses it as:
 "The software is completely free for any purpose, unless notes at the
head of the
 program text indicates otherwise (which is rare). In any case, the
notes about
 licensing are never more restrictive than the BSD License."
 .
 (see: http://tartarus.org/~martin/PorterStemmer/ ,FAQ, #1 )
 .
 The current author licenses it as the rest of the project.
```


# DPMT
If you want to maintain this package under the Debian Python Modules Team,
please read https://python-modules.alioth.debian.org/policy.html and apply
to the team :).
Don't hesistate to chime in at #debian-python @ irc.oftc.net

# gbp.conf

I haven't looked much, but please make sure the repo complies with [3].


# lintian

there's a spelling error in manpage: accomodate accommodate (upstream
the fix).


[1]: https://github.com/jamesturk/jellyfish/issues/48
[2]:
https://anonscm.debian.org/cgit/python-modules/packages/python-proselint.git/tree/debian/control
[3]: https://github.com/diego-plan9/python-jellyfish-mentors




-- 
Víctor Cuadrado juan

E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Diego M. Rodriguez]

Hello Nicholas,

> I believe the package also needs Build-Depends on libpython-all-dev and
> libpython3-all-dev, or the C extensions fail (nonfatally) to compile in a 
> clean
> chroot environment.

thanks for the hint - the Build-Depends are indeed needed for successfully
building the C extensions, my apologies for the oversight. I'll make sure to
use a clean chroot for building in the future.

> Unfortunately, the tests also fail - it appears that pytest is not 
> successfully
> picking up any tests to run:

thanks as well for pointing it out. It seems that upstream is not strictly
following the standard pytest naming convention for test files, and relying
instead of on some setup.py magic for running the unit tests. I have appended
the following lines to debian/rules, pointing pytest to the right file and
making the testdata .csv files available during testing:

export PYBUILD_BEFORE_TEST = cp -R {dir}/testdata {build_dir}
export PYBUILD_AFTER_TEST = rm -R {build_dir}/testdata
export PYBUILD_TEST_ARGS = jellyfish/test.py

This seemed a bit less intrusive than renaming the jellyfish/test.py file. The
package on mentors and the temporary CVS repository [1] have been updated with
these two changes, as well as including a README.Debian file with some
clarifications about the naming after some discussion at [2].

Additionally, I noticed that the tests result in an error if using the pytest
version at Debian jessie (2.6.3-2):

 ERRORS 
__ ERROR collecting jellyfish/test.py __
/usr/lib/python3/dist-packages/_pytest/runner.py:139: in __init__
self.result = func()
...
/usr/lib/python3/dist-packages/_pytest/python.py:824: in parametrize
if ids and len(ids) != len(argvalues):
E   TypeError: object of type 'type' has no len()
=== 1 error in 0.08 seconds 

but they do pass using the pytest version at stretch and above. The culprit
seems to be the usage of the "ids" parameter of the parametrize decorator,
which is set to the built-in "str" on a handful of cases:

jellyfish/test.py:38
@pytest.mark.parametrize("s1,s2,value", _load_data('jaro_winkler'), ids=str)

Older versions of pytest seem to require that the "ids" parameters is strictly
a list or None, not handling callables properly.

I'm wondering what would be the recommended way to deal with situation: would
simply modifying the pytest build-depend so it requires a specific version or
above suffice (even if it might make testing on a stable chroot impossible)?
After some light inspection, it seems that this could probably be solved as
well by a patch that replaces "str" with a valid value (or drops it), and I'd
be happy to follow that path as well, or further inspect the situation.

Again, thanks a look for your insights and taking a look at the package!

[1] https://github.com/diego-plan9/python-jellyfish-mentors
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#12

-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Paul R. Tagliamonte]

Hey all,

I'm willing to sponsor this package and any related packages.

 Paul

On Mon, Dec 28, 2015 at 1:29 PM, Diego M. Rodriguez 
wrote:

> Hello Nicholas,
>
> > I believe the package also needs Build-Depends on libpython-all-dev and
> > libpython3-all-dev, or the C extensions fail (nonfatally) to compile in
> a clean
> > chroot environment.
>
> thanks for the hint - the Build-Depends are indeed needed for successfully
> building the C extensions, my apologies for the oversight. I'll make sure
> to
> use a clean chroot for building in the future.
>
> > Unfortunately, the tests also fail - it appears that pytest is not
> successfully
> > picking up any tests to run:
>
> thanks as well for pointing it out. It seems that upstream is not strictly
> following the standard pytest naming convention for test files, and relying
> instead of on some setup.py magic for running the unit tests. I have
> appended
> the following lines to debian/rules, pointing pytest to the right file and
> making the testdata .csv files available during testing:
>
> export PYBUILD_BEFORE_TEST = cp -R {dir}/testdata {build_dir}
> export PYBUILD_AFTER_TEST = rm -R {build_dir}/testdata
> export PYBUILD_TEST_ARGS = jellyfish/test.py
>
> This seemed a bit less intrusive than renaming the jellyfish/test.py file.
> The
> package on mentors and the temporary CVS repository [1] have been updated
> with
> these two changes, as well as including a README.Debian file with some
> clarifications about the naming after some discussion at [2].
>
> Additionally, I noticed that the tests result in an error if using the
> pytest
> version at Debian jessie (2.6.3-2):
>
>  ERRORS
> 
> __ ERROR collecting jellyfish/test.py
> __
> /usr/lib/python3/dist-packages/_pytest/runner.py:139: in __init__
> self.result = func()
> ...
> /usr/lib/python3/dist-packages/_pytest/python.py:824: in parametrize
> if ids and len(ids) != len(argvalues):
> E   TypeError: object of type 'type' has no len()
> === 1 error in 0.08 seconds
> 
>
> but they do pass using the pytest version at stretch and above. The culprit
> seems to be the usage of the "ids" parameter of the parametrize decorator,
> which is set to the built-in "str" on a handful of cases:
>
> jellyfish/test.py:38
> @pytest.mark.parametrize("s1,s2,value", _load_data('jaro_winkler'),
> ids=str)
>
> Older versions of pytest seem to require that the "ids" parameters is
> strictly
> a list or None, not handling callables properly.
>
> I'm wondering what would be the recommended way to deal with situation:
> would
> simply modifying the pytest build-depend so it requires a specific version
> or
> above suffice (even if it might make testing on a stable chroot
> impossible)?
> After some light inspection, it seems that this could probably be solved as
> well by a patch that replaces "str" with a valid value (or drops it), and
> I'd
> be happy to follow that path as well, or further inspect the situation.
>
> Again, thanks a look for your insights and taking a look at the package!
>
> [1] https://github.com/diego-plan9/python-jellyfish-mentors
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#12
>
> --
> Diego M. Rodriguez
> 36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232
>
>


-- 
:wq

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Nicholas Breen]

On Tue, Dec 08, 2015 at 09:44:01PM +0100, Diego M. Rodriguez wrote:
> I am looking for a sponsor for my package "python-jellyfish"
> 
> * Package name: python-jellyfish
>   Version : 0.5.1-1
>   Upstream Author : James Turk 
> * URL : https://github.com/jamesturk/jellyfish
> * License : BSD-2-clause
>   Section : python

Hi Diego,

I believe the package also needs Build-Depends on libpython-all-dev and
libpython3-all-dev, or the C extensions fail (nonfatally) to compile in a clean
chroot environment.

Unfortunately, the tests also fail - it appears that pytest is not successfully
picking up any tests to run:

[...]
I: pybuild base:184: cd 
/tmp/buildd/python-jellyfish-0.5.1/.pybuild/pythonX.Y_2.7/build; python2.7 -m 
pytest 
= test session starts ==
platform linux2 -- Python 2.7.11, pytest-2.8.5, py-1.4.31, pluggy-0.3.1
rootdir: /tmp/buildd/python-jellyfish-0.5.1, inifile: 
collected 0 items

= no tests ran in 0.00 seconds =
E: pybuild pybuild:274: test: plugin distutils failed with: exit code=5: cd 
/tmp/buildd/python-jellyfish-0.5.1/.pybuild/pythonX.Y_2.7/build; python2.7 -m 
pytest 
[...]



-- 
Nicholas Breen
nbr...@debian.org

Bug#807432: RFS: python-jellyfish/0.5.1-1 [ITP]

[Diego M. Rodriguez]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-jellyfish"

* Package name: python-jellyfish
  Version : 0.5.1-1
  Upstream Author : James Turk 
* URL : https://github.com/jamesturk/jellyfish
* License : BSD-2-clause
  Section : python

It builds those binary packages:

python-jellyfish - Library for approximate and phonetic matching of strings 
(Python 2)
python-jellyfish-doc - Library for approximate and phonetic matching of strings 
(documentation)
python3-jellyfish - Library for approximate and phonetic matching of strings 
(Python 3)

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/python-jellyfish


Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/p/python-jellyfish/python-jellyfish_0.5.1-1.dsc

More information about python-jellyfish can be obtained from 
https://github.com/jamesturk/jellyfish.

Regards,
 Diego M. Rodriguez



signature.asc
Description: Digital signature