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

Bug#825112: (no subject)



On Jun 07, 2016, at 10:00 PM, Gordon Ball wrote:

>> The packaging looks really good.  I noticed the setting of http_proxy in
>> override_dh_auto_build.  You probably don't strictly need that because I
>> believe pybuild does that automatically.  It can't hurt though and some
>> maintainers prefer to be explicit about that.  
>
>The http_proxy bit was cargo-culted from
>https://wiki.debian.org/Python/LibraryStyleGuide

Ah, I'd forgotten that this was still needed for sphinx-build.

>Good idea. The test suite is extensive but it hadn't occurred to me that
>it is entirely based on importing it as a library rather than actually
>running the binary. I'd tested the installed package but clearly on a
>system with python3-pkg-resources already installed.
>
>I found that this fails in an autopkgtest schroot though - xonsh fails
>to start if $HOME is not writable (which is possibly a bug), so I've
>added a wrapper which sets $HOME=$ADTTMP (and added a couple of extra
>examples).

Looks great, much better than my quick hack. :)

>On hold for the moment then. I'm happy to have it listed as team maintained
>at a future point though. I'm already subscribed to debian-python, I'll apply
>to join the relevant teams soon.

Cool.  It'll be easy to move later.

One possible minor issue is that DPMT did adopt git-dpm for packages, but
since that decision several years ago, git-dpm has apparently stopped being
developed.  It hasn't quite bitrotted yet, but I am advocating that DPMT drop
git-dpm and use gbp-pq for patch management.  I don't see any reason other
than (hopefully temporary) consistency for PAPT to adopt git-dpm once that
switch happens.  We'll have to see what the team says.

For now, let's just assume gbp-pq will be adopted for PAPT.

>Given the script is generated based on `entry_points` in setup.py,
>shouldn't this dependency be generated by pybuild/dh_python?

Actually, that should come from an install_requires section or a
requirements.txt file.  I don't see either of those in the xonsh repo.  But
also pkg_resources is kind of a special case on Debian.  It really comes as
part of setuptools, but in Debian we split it out into a separate binary
package, so I don't know that it would be automatically detected in any case.
Clearly it doesn't since it crashes without an explicit Depends, but we'd have
to ask Piotr on debian-python@ to know whether that's intended behavior or
not.  TBH, I always just add it explicitly.

>There are a couple of remaining (possibly non-) issues:
>
> * lintian reports privacy-breach-generic on the documentation (google
>webfont links). I can't see this explicitly configured anywhere in the
>rst files or conf.py, so I *think* this is being added by
>sphinx/cloud-sptheme

Interesting.  I built the package from the git repo on unstable and ran
lintian over the amd64.changes file.  I don't get any lintian warnings.

> * building the documentation generates (I think) inconsequential errors
>since the xonsh pygments lexer is not available at build time; this
>could be fixed by build-depending on itself, but I'm not sure this is
>worth adding a dependency cycle for.

I see that too.  Agreed it's probably not worth worrying about right now.

> * xonsh supports installing itself as a jupyter kernel, which I'm
>interested to include but for the moment (parts of) jupyter is only in
>experimental, so it can probably wait until a future xonsh upload

+1

Everything else lgtm.  Let me know when you want me to sponsor an upload; I'm
happy to do it any time.  It will have to go through NEW of course, but it
would be nice to get this into peoples hands soon.  (I know I'm not the only
Debuntunista who wants to use it after watching the Pycon talk. :)

Attachment: pgpW7RUwl9wq8.pgp
Description: OpenPGP digital signature


Reply to: