Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

[Ghislain Vaillant]

Le mer. 29 sept. 2021 à 23:14, Dominik George  a
écrit :

>
> > and that will require an upstream new release, which does not help
> > when you want/need to package the current one
>
> Most upstreams kindly make . post releases immediately.
>

I found that to be pretty rare in my own experience.

>
Maybe I am just lucky with upstreams...
>

You are, indeed.

Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

[Dominik George]

> and that will require an upstream new release, which does not help
> when you want/need to package the current one

Most upstreams kindly make . post releases immediately.

Maybe I am just lucky with upstreams...

-nik

Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

[Sandro Tosi]

> That's an upstream bug then, and upstream should fix that and ship a complete 
> source tarball.
>
> I always submit pull requests updating MANIFEST.in and until now, all 
> upstreams have accepted them.

and that will require an upstream new release, which does not help
when you want/need to package the current one.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

[Jeremy Stanley]

On 2021-09-29 16:32:05 -0400 (-0400), Sandro Tosi wrote:
> > One note: I'd consider watching for PyPI instead of GitHub.
> 
> there was actually a recent discussion on this list, discouraging
> from using PyPI in favor of github, since GH tarball usually
> contains docs, tests, and other files useful when building from
> source, usually not included in tarball released to users, ie pypi

And as was also pointed out in that discussion, this depends a lot
on the upstream maintainers and their workflow. Some upstreams are
careful to always include all files from the Git worktree within
their sdist tarballs, but may also include required files which
aren't contained in their Git worktree (such as version information,
copyright holders, or release notes extracted from Git tags,
revision history, Git "notes" refs, and so on)... in which cases you
either need their sdist or the full Git repository, since a "GitHub
tarball" of the worktree alone is insufficient to reproduce this
information.

Also since the advent of "wheels" a lot of maintainers are more
willing to make their sdists full archives of their projects (as was
the original intent for a "source distribution" package), since most
users installing directly from PyPI are going to pull a wheel
instead of an sdist when available, and wheels are expected to be
much more pared down anyway.

Like many things in the packaging realm, there is no
one-size-fits-all answer.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

[Dominik George]

> there was actually a recent discussion on this list, discouraging from
> using PyPI in favor of github, since GH tarball usually contains docs,
> tests, and other files useful when building from source, usually not
> included in tarball released to users, ie pypi

That's an upstream bug then, and upstream should fix that and ship a complete 
source tarball.

I always submit pull requests updating MANIFEST.in and until now, all upstreams 
have accepted them.

-nik

Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

[Sandro Tosi]

> One note: I'd consider watching for PyPI instead of GitHub.

there was actually a recent discussion on this list, discouraging from
using PyPI in favor of github, since GH tarball usually contains docs,
tests, and other files useful when building from source, usually not
included in tarball released to users, ie pypi

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Request to join Debian Python Team

[Vasudev Kamath]

Hi,

I would like to reintroduce foolscap [1] which is part of DPT back to
unstable as it is a dependency for reintroducing tahoe-lafs which I used
to maintain earlier in Debian.

Salsa login: vasudev

I've gone through
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
and accept the policy.

PS: I'm not subscribed to debian-python@l.d.o so keep me in CC on
reply

[1] https://tracker.debian.org/pkg/foolscap

Thanks and Regards,
Vasudev

Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

[Dominik George]

Hi,

> Could someone please upload this little package ? It's a dependency of
> xsdata, an awesome XML/dataclasses library I'd like to get into the archive.

uploaded, thanks for your contribution!

One note: I'd consider watching for PyPI instead of GitHub.

Cheers,
Nik

Re: Potential issue with numpy

[Andreas Tille]

On Wed, Sep 29, 2021 at 11:27:23AM -0400, Sandro Tosi wrote:
> Please do report bugs in the BTS when there's a problem with a package

#995318

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Re: Potential issue with numpy

[Sandro Tosi]

Please do report bugs in the BTS when there's a problem with a package

On Wed, Sep 29, 2021 at 10:32 AM Andreas Tille  wrote:
>
> Hi,
>
> in the issue I filed against nipype I was asked to try to rebuild numpy
> and see whether this might make a diffence.  So I tried
>
>   dget http://deb.debian.org/debian/pool/main/n/numpy/numpy_1.19.5-1.dsc
>   cd numpy-1.19.5
>
> and have rebuild it in a recent pbuilder environment.  This ends up in
>
> DISTUTILS.rst.txt:386: WARNING: Unparseable C cross-reference: '/**end 
> repeat1**/'
> Invalid C declaration: Expected identifier in nested name. [error at 0]
>   /**end repeat1**/
>   ^
>
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 280, in 
> build_main
> app.build(args.force_all, filenames)
>   File "/usr/lib/python3/dist-packages/sphinx/application.py", line 337, in 
> build
> self.builder.build_update()
>   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> 293, in build_update
> self.build(to_build,
>   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> 357, in build
> self.write(docnames, list(updated_docnames), method)
>   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> 531, in write
> self._write_serial(sorted(docnames))
>   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> 541, in _write_serial
> self.write_doc(docname, doctree)
>   File "/usr/lib/python3/dist-packages/sphinx/builders/html/__init__.py", 
> line 626, in write_doc
> self.docwriter.write(doctree, destination)
>   File "/usr/lib/python3/dist-packages/docutils/writers/__init__.py", line 
> 78, in write
> self.translate()
>   File "/usr/lib/python3/dist-packages/sphinx/writers/html.py", line 70, in 
> translate
> self.document.walkabout(visitor)
>   File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
> walkabout
> if child.walkabout(visitor):
>   File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
> walkabout
> if child.walkabout(visitor):
>   File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
> walkabout
> if child.walkabout(visitor):
>   [Previous line repeated 1 more time]
>   File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 206, in 
> walkabout
> visitor.dispatch_visit(self)
>   File "/usr/lib/python3/dist-packages/sphinx/util/docutils.py", line 477, in 
> dispatch_visit
> method(node)
>   File "/usr/lib/python3/dist-packages/sphinx/writers/html5.py", line 417, in 
> visit_literal_block
> highlighted = self.highlighter.highlight_block(
>   File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 149, in 
> highlight_block
> lexer = self.get_lexer(source, lang, opts, force, location)
>   File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 127, in 
> get_lexer
> lexer = lexer_classes[lang](**opts)
> TypeError: 'NumPyLexer' object is not callable

there's a new sphinx version in unstable (4.2.0), likely other pieces
of the infrastructure around numpy and its doc need updating. The fact
we dont have access to the build log makes it hard to pin point the
issue.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Potential issue with numpy

[Andreas Tille]

Hi,

in the issue I filed against nipype I was asked to try to rebuild numpy
and see whether this might make a diffence.  So I tried

  dget http://deb.debian.org/debian/pool/main/n/numpy/numpy_1.19.5-1.dsc
  cd numpy-1.19.5

and have rebuild it in a recent pbuilder environment.  This ends up in

DISTUTILS.rst.txt:386: WARNING: Unparseable C cross-reference: '/**end 
repeat1**/'
Invalid C declaration: Expected identifier in nested name. [error at 0]
  /**end repeat1**/
  ^

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 280, in 
build_main
app.build(args.force_all, filenames)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 337, in 
build
self.builder.build_update()
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 293, 
in build_update
self.build(to_build,
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 357, 
in build
self.write(docnames, list(updated_docnames), method)
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 531, 
in write
self._write_serial(sorted(docnames))
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 541, 
in _write_serial
self.write_doc(docname, doctree)
  File "/usr/lib/python3/dist-packages/sphinx/builders/html/__init__.py", line 
626, in write_doc
self.docwriter.write(doctree, destination)
  File "/usr/lib/python3/dist-packages/docutils/writers/__init__.py", line 78, 
in write
self.translate()
  File "/usr/lib/python3/dist-packages/sphinx/writers/html.py", line 70, in 
translate
self.document.walkabout(visitor)
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
walkabout
if child.walkabout(visitor):
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
walkabout
if child.walkabout(visitor):
  [Previous line repeated 1 more time]
  File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 206, in 
walkabout
visitor.dispatch_visit(self)
  File "/usr/lib/python3/dist-packages/sphinx/util/docutils.py", line 477, in 
dispatch_visit
method(node)
  File "/usr/lib/python3/dist-packages/sphinx/writers/html5.py", line 417, in 
visit_literal_block
highlighted = self.highlighter.highlight_block(
  File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 149, in 
highlight_block
lexer = self.get_lexer(source, lang, opts, force, location)
  File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 127, in 
get_lexer
lexer = lexer_classes[lang](**opts)
TypeError: 'NumPyLexer' object is not callable

Exception occurred:
  File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 127, in 
get_lexer
lexer = lexer_classes[lang](**opts)
TypeError: 'NumPyLexer' object is not callable
The full traceback has been saved in /tmp/sphinx-err-h3bd2cwr.log, if you want 
to report the issue to the developers.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
A bug report can be filed in the tracker at 
. Thanks!


While I think this could be worth a "does not build from source" bug
against numpy (I'd wait with this until somebody confirms) I wonder
what answer I should give to nipype upstream in the issue[1].

Kind regards

 Andreas.


[1] https://github.com/nipy/nipype/issues/3382

-- 
http://fam-tille.de

Re: RFS: still looking for sponsor for new version of sentry-python (#990519)

[Eberhard Beilharz]

Hi Sandro,

Thanks for your reply!

Sandro Tosi wrote on 28.09.21 19:00:


This package repository is hosted on the Debian Python Team salsa
group, at https://salsa.debian.org/python-team/packages/sentry-python
while you're proposing an upload outside of this setup via Mentors.
It's usually inappropriate to seek outside sponsors for
team-maintained packages, because that tends to leave the canonical
git repo outdated, forcing people to do extra work to reconcile
history.
Ahh, that's how it works here . Every Debian team does it a little 
differently. Makes sense.


Please submit a MR for the upstream, pristine-tar, and master branches
(one MR for each branch) with your changes on salsa, and we can review
them.

Done:

https://salsa.debian.org/python-team/packages/sentry-python/-/merge_requests/1

https://salsa.debian.org/python-team/packages/sentry-python/-/merge_requests/2

https://salsa.debian.org/python-team/packages/sentry-python/-/merge_requests/3

Thanks,
    Eberhard