Request to join the DPMT
Dear Debian Python Modules Team, I would like to join the team with the initial goal of maintaining the python-jellyfish package, which has currently ITP [1] and RFS [2] status, under the umbrella and guidance of the team. The jellyfish package is a dependency needed for updating the beets [3] package, which I currently contribute to in the upstream repository [4]. Once I learn the ropes, I would love to lend a hand with any other packages - not only beets itself but hopefully any other packages that need work, in the hopes of giving back to Debian after many years being a regular user. I have been working professionally with Python for the last 5 years in a number of projects, most of them related to Django as well, and occasionally make some small-time code contributions to related packages on their ecosystem (such as django-extensions and py-authorize). Alternatively, I'd also welcome guidance and/or sponsorship, in case joining the team is deemed a bit premature or undesired for any reason. I have worked on the package for the last couple of weeks on mentors [5], hopefully adhering to the recommended Debian practices, but the work has not been formally reviewed yet. My alioth login name is "diegom-guest". I have read the DPMT policy [6] and I accept it. Best regards, [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807432 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775719 [4] https://github.com/sampsyo/beets/commits/master?author=diego-plan9 [5] https://mentors.debian.net/package/python-jellyfish [6] http://python-modules.alioth.debian.org/policy.html -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Re: Enabling Python bindings for jellyfish
On Tue, Dec 29, 2015 at 12:56:20PM -0500, Scott Kitterman wrote: > I think the respective maintainers should talk and then discuss with their > upstreams as the collision potential isn't just in Debian. I'm chiming in as the (prospective) maintainer of the ITP python-jellyfish package, just to note that I have discussed it with Andreas [1] and fully agreed to rename "my" package. The choice of name was due to not being aware of the Python bindings on the existing DNA-jelyfish package (and in part also due to my inexperience on these matters), and I have contacted upstream earlier today in the hopes of coming up with a good alternative name. I'd be happy to follow up on the discussion with upstream once I get a reply, in order to find out if he would be open to solving the conflict at a "higher" level. Best regards, [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#42 -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Re: Enabling Python bindings for jellyfish
On Tue, Dec 29, 2015 at 02:07:05PM -0500, Paul Tagliamonte wrote: > That won't solve the problem, since both will provide the python module > jellyfish Fair point indeed, and I fully agree that ideally the problem should be solved at the python module level. I'm wondering if you or other senior, more experienced developers could suggest what would be the recommended solution for the namespace conflict, taking into account: a) DNA-jellyfish is an stablished Debian package since 2011 [1] b) STR-jellyfish is on PyPI [2] since 2010 (version 0.1) c) both packages started their Github repos around the same time (summer 2010) d) both packages seem to be a bit "niche" (popcon stats for "jellyfish" [3] and "beets" [4], the package that would depend on STR-jellyfish, seem to hint that they are both modestly used within Debian and cater to specific groups of users) e) other considerations I'm probably missing! I would personally place a bit more weight on the fact that STR-jellyfish is already on PyPI (based on the rationale that it is arguably the "de facto" repository for Python packaging); but, again, I am relatively new to Debian practices and arguing for keeping consistency within the Debian repository seems reasonable to me as well. Best regards, [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644925 [2] https://pypi.python.org/pypi/jellyfish [3] https://qa.debian.org/popcon.php?package=jellyfish [4] https://qa.debian.org/popcon.php?package=beets > > On Tue, Dec 29, 2015 at 1:24 PM, Diego M. Rodriguez > wrote: > > > On Tue, Dec 29, 2015 at 12:56:20PM -0500, Scott Kitterman wrote: > > > I think the respective maintainers should talk and then discuss with > > their > > > upstreams as the collision potential isn't just in Debian. > > > > I'm chiming in as the (prospective) maintainer of the ITP python-jellyfish > > package, just to note that I have discussed it with Andreas [1] and fully > > agreed to rename "my" package. The choice of name was due to not being > > aware > > of the Python bindings on the existing DNA-jelyfish package (and in part > > also > > due to my inexperience on these matters), and I have contacted upstream > > earlier today in the hopes of coming up with a good alternative name. > > > > I'd be happy to follow up on the discussion with upstream once I get a > > reply, > > in order to find out if he would be open to solving the conflict at a > > "higher" > > level. > > > > Best regards, > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806716#42 > > -- > > Diego M. Rodriguez > > 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 > > > > > > > -- > All programmers are playwrights, and all computers are lousy actors. > > #define sizeof(x) rand() > :wq -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Re: Enabling Python bindings for jellyfish
> That bit of policy doesn't officially kick in yet since these aren't both in > the > archive yet. The policy is about consensus finding and not winning and > losing. > That's why I recommended discussing with the upstreams (and hopefully getting > them in direct communication). Thanks for the pointer to the relevant Debian Policy chapter, Scott. My previous message was indeed intented to hopefully serve as a common ground towards reaching a consensus and as an aid when taking the discussion upstream, rather than force or impose a decision - my apologies if it came too strong! -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Re: Request to join the DPMT
> Welcome to the team. > > Scott K Thank you - looking forward to a fruitful collaboration! Best regards, -- Diego M. Rodriguez 36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232 signature.asc Description: Digital signature
Re: Bug#806716: Jellyfish name conflicts
Hello Andreas,
> This was not really intended but now it happened. We now need to
> decide about the two options:
>
> 1. Cancel the upload to new and drop the python3-jellyfish package
> 2. Just leave this as is and follow the advise of the jellyfish
> author quoted on top of this mail to the python list[4] to
> rename just the Python module.
>
> I think option 2. is better for all parts and if you agree I'd
> immediately cancel the upload to new.
thanks for the detailed clarification on the events surrounding the
package and the prompt response!
I would be happy to go with either option (personally leaning towards
option 2 as well), and basically rely on your expertise - the upstream
string-jellyfish author has explicitely mentioned that he has no strong
opinion on the Debian package name and I don't have either.
With this in mind, I'm wondering if this would be a good time to rename
this ITP and the RFS (and the mentors package, etc) to the hopefully
final Debian package name ("python-jellyfishstr"?)?
Best regards,
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
Re: Bug#806716: Jellyfish name conflicts
Hello Andreas,
> H, ftpmaster was fast - now python-jellyfish is accepted. This only
> leaves us option 2 without fiddling around to much.
I noticed - and feels like yet another argument in favour of option 2.
If there is something I can do to help with the renaming of the DNA
jellyfish python module (collaborating on the upstream repository,
gathering more opinions on the matter, or anything else) I'd be willing
to lend a hand, just let me know!
> > With this in mind, I'm wondering if this would be a good time to rename
> > this ITP and the RFS (and the mentors package, etc) to the hopefully
> > final Debian package name ("python-jellyfishstr"?)?
>
> The latter sounds sensible. Sorry for all the confusion and leaving you
> alone a bit with this issue.
Thanks for sharing your thoughts on the package renaming issue, and no
worries at all - I really apreciate your guidance and efforts on helping
move this issue forward.
Best regards,
--
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B FF9B B6C4 B901 06BC E232
signature.asc
Description: Digital signature
Re: Updating pip
On 1/24/20 8:00 PM, Scott Kitterman wrote: > I would suggest that people who decide to work on one of the above reply to > this message so we don't end up with people doing duplicate works. I can work on bumping "progress". Best, -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Re: Help fixing #959558 (case: FTBFS: AttributeError: 'tuple' object has no attribute 'lstrip' with sphinx 2.4)
On 5/26/20 11:06 PM, Scott Talbert wrote: > It looks like it's a bug in sphinx. I'm suspecting the same - and I was also not able to reproduce it in a local installation (pip-installed sphinx trying to match the dependencies and versions). However, it seems the culprit is at "case/mock.py":51: call = mock.call In case a new upload of sphinx does not land in time, perhaps a workaround along the lines of: diff --git a/docs/reference/case.mock.rst b/docs/reference/case.mock.rst index 1a28a5c..2b6562c 100644 --- a/docs/reference/case.mock.rst +++ b/docs/reference/case.mock.rst @@ -9,3 +9,4 @@ .. automodule:: case.mock :members: :undoc-members: +:exclude-members: call might be acceptable? While not the ideal solution, the upstream generated docs [1] end up including the docstring from "unittest.mock._Call" [2] for that member, which might not provide too much relevant info for end users anyway (and the inheritance from "tuple" might be related to the original error). [1] https://case.readthedocs.io/en/latest/reference/case.mock.html#case.mock.call [2] https://github.com/python/cpython/blob/3.8/Lib/unittest/mock.py#L2352 -- Diego M. Rodriguez signature.asc Description: OpenPGP digital signature
Bug#993797: ITP: python-beniget -- collection of compile-time Python AST analyzers
Package: wnpp X-Debbugs-Cc: debian-python@lists.debian.org, debian-scie...@lists.debian.org Owner: "Diego M. Rodriguez" Severity: wishlist * Package name: python-beniget Version : 0.4.1 Upstream Author : Serge Guelton * URL : https://github.com/serge-sans-paille/beniget * License : BSD Programming Lang: Python Description : collection of compile-time Python AST analyzers Collection of compile-time analyzers of Python Abstract Syntax Trees that can be used as building blocks to write static analyzers or compilers: * Ancestors: map a node to the list of its enclosing nodes * DefUseChains: map a node to the list of definition points in that node * UseDefChains: map a node to its list of potential definitions This package is a dependency of ITP "pythran" [1]. My intent is to package this software under the umbrella of the Debian Python team. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143 --- Diego M. Rodriguez
Bug#993800: ITP: python-gast -- compatibility layer for the AST of various Python versions
Package: wnpp X-Debbugs-Cc: debian-python@lists.debian.org Owner: "Diego M. Rodriguez" Severity: wishlist * Package name: python-gast Version : 0.5.2 Upstream Author : Serge Guelton * URL : https://github.com/serge-sans-paille/gast * License : BSD Programming Lang: Python Description : compatibility layer for the AST of various Python versions Provides an homogeneous API over the Abstract Syntax Trees of various Python versions (including Python 2 and Python 3), which itself is compatible with the standard library "ast" module API. This package is a dependency of ITP "pythran" [1] (and also of ITP "beniget" [2], another dependency itself). My intent is to package this software under the umbrella of the Debian Python team. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993797 --- Diego M. Rodriguez
