[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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

Attachment: signature.asc
Description: Digital signature


Reply to: