Bug#825112: (no subject)
On 07/06/16 22:49, Barry Warsaw wrote:
> 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.
I don't see anything locally, but I do see it when uploading a binary
package to mentors.d.n - I'm unsure how their setup differs from
`lintian --pedantic`. Anyway.
>
>> * 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. :)
>
If you think it looks in good shape, let's go for an upload. Thanks for
your time reviewing the packaging.
Reply to: