Re: Status of https://debian-python.readthedocs.io/en/latest/

Hi Sandro, That RTD project has been failing for years. It looks like I’m the only maintainer for that project. I’m happy to add others or transfer it to someone else. I don’t think RTD supports maintainer teams. Just let me know what y’all want to do! Cheers, -Barry > On Dec 25, 2020,

Scaling back for now

After the events of April, I've realized that I have a lot less time, and to be frankly honest, motivation for contributing to Debian right now. So I'm scaling back, but not retiring. I've tried to reflect my current level of participation by updating the packages for which I was sole or primary

Re: MBF for deprecating Python2 usage

On Aug 7, 2017, at 20:52, Ben Finney wrote: > > So IMO the conservative assumption is that they expect Debian to provide > the stability it is famous for, and not to break the behaviour of > commands unnecessarily. There’s another dimension to that too: it’s people who

Re: MBF for deprecating Python2 usage

On Aug 7, 2017, at 18:28, Ben Finney wrote: > The issue is: Invoking ‘python’ today gets an interpereter, Python 2, > that will work with some code and not others. It should not tomorrow > invoke an incompatible interpreter without *knowing* that the vast > majority of

Re: MBF for deprecating Python2 usage

On Aug 7, 2017, at 14:52, Diane Trout wrote: > Perhaps when launching via the command "python" the interpreter could > hint python2 was available? Something like: > > $ python > Python 3.5.4rc1 (default, Jul 25 2017, 08:53:34) > [GCC 6.4.0 20170704] on linux > Type "python2" for

Re: a few quick questions on gbp pq workflow

On Aug 6, 2017, at 11:11, Ondrej Novy wrote: > It's not always possible/simple/nice to use sdist, because it contains > prebuild docs. And I don't like to do +dfsg rebuild just for removing docs. > Sometimes sdists doesn't contain tests. I will also generally prefer the PyPI

Re: MBF for deprecating Python2 usage

Scott Kitterman wrote: > If the primary concern is what happens when a user types "python", then can > we > address that in command-not-found and leave /usr/bin/python out of it? I'm definitely willing to for now. It's clearly not time to remove the link or point it elsewhere anyway. I think

Re: MBF for deprecating Python2 usage

Ole Streicher wrote: > It is very usual to use "#!/usr/bin/env python" as shebang, exactly for > the case that python is not installed in /usr/bin. Sure, but then all bets are off. The script so shebanged can't assume anything about $PATH so it gets whatever it gets. Using /usr/bin/env in

Re: Python3.6 plans for Buster

On Jun 17, 2017, at 04:20 AM, Scott Kitterman wrote: >Last time I compared my understanding of the Buster schedule with the >python3.7 schedule, I recall concluding that we'd likely be on python3.6 for >the Buster release (not sure that's still true). If so, we only have to do >this once this

Re: Ad-hoc Debian Python BoF at PyCon US 2017

On Jun 06, 2017, at 10:57 AM, Sandro Tosi wrote: >if we plan (and it looks like we do) to support and distribute 2.7 >with buster, why not support it *properly*? what's the point of >deprecating python2.7? either we ship it or not, but if we do then >let's not cripple it by removing python2

Re: PAPT git migration

On May 31, 2017, at 08:58 PM, Stefano Rivera wrote: >It's been a while, but I found some time and energy at PyCon, to work >our SVN->Git migration. Thanks for all your great work on this Stefano! >Here's what the migration currently looks like [0]. >[0]:

Re: python-parse-type

On May 16, 2017, at 08:10 PM, Brian May wrote: >python-enum - robust enumerated type support in Python >python3-enum34 - backport of Python 3.4's enum package Oh yeah, that too. :) -Barry

Re: python-parse-type

On May 16, 2017, at 11:51 AM, Piotr Ożarowski wrote: >packaged as python-enum34 (correct name is python-enum, that's why you >didn't find it most probably) > >Barry: ;-P Why is that wrong? Agreed it's perhaps less discoverable in this case, but if you were looking for the PyPI enum34 package in

Re: Request to join DPMT

On May 11, 2017, at 10:14 AM, Colin Watson wrote: >I'd like to join the Debian Python Modules Team. I maintain a couple of >module packages already that probably ought to be moved under the DPMT >umbrella (six, python-tblib), and I'm upstream for some others (e.g. >lazr.restfulclient,

Re: Joining the team

On Apr 09, 2017, at 01:13 PM, sab wrote: >https://mentors.debian.net/package/python-zxcvbn > >with DPMT as uploader. What's my next step? Have I to create a Git repository? Welcome to the team Sabino. You'll want to take a look at these two wiki pages. First is the style guide for DPMT

Heads up about file name changes

As Ubuntu 17.04 development winds down, I've been spending a fair bit of time looking at FTBFS. For packages that have been copied from Debian, especially Python ones, we try really hard not to introduce too many deltas. Doko usually does archive-wide test rebuilds at various times during the

What should Debian do about Python 2? (was Re: next version of csvkit)

On Apr 01, 2017, at 05:12 PM, Ghislain Vaillant wrote: >Pasting the relevant quotes below: > >"The 2.x series of Python is due for deprecation and will not be maintained >past 2020 so it is recommended that Python 2 modules are not packaged unless >necessary." It's true that upstream will almost

Re: PyPI source or github source?

On Mar 14, 2017, at 08:16 AM, Brian May wrote: >I just found another one: python-ledger. Unfortunately in this case, >Python packages are also bundled with the C code (libraries and client). Not entirely relevant, but pyparted also contained C code, but its mainline does support Python 3.

Re: PyPI source or github source?

On Mar 13, 2017, at 05:55 PM, Thomas Goirand wrote: >IMO, upstream are right that the PyPi releases should be minimal. They >are, from my view point, a binary release, not a source release. Wheels should be considered a binary release, but tarballs should still be considered the canonical source

Re: PyPI source or github source?

On Mar 12, 2017, at 01:19 PM, Brian May wrote: >Should we be using PyPI as our source of packages? Or github? PyPI for two reasons: not every developer uses git, and even those that do may not use GitHub. I've so far only encountered one package that releases on GitHub and not PyPI: pyparted.

Re: GnuPG signatures on PyPI: why so few?

On Mar 12, 2017, at 11:46 AM, Ben Finney wrote: >What prospect is there in the Python community to get signed upstream >releases become the obvious norm? I don't know. Digital security seems to be mostly an afterthought unfortunately. I always use `twine upload --sign` so all my projects have

Re: Adopting OpenStack packages

On Mar 06, 2017, at 10:32 AM, Scott Kitterman wrote: >I think it's reasonable to try this out on a branch for some number of >packages and write documentation (the documentation for using git with >git-dpm in DPMT is excellent and I don't think we should regress in that >area). Once that's done,

Re: Adopting OpenStack packages

On Mar 05, 2017, at 01:47 AM, Thomas Goirand wrote: >Why waiting? The freeze is typically a time of very low activity and low >disturbance. That's a perfect moment for doing the switch. I think it's generally been the consensus, even outside of this team, that doing vcs or other disruptive

Re: Backport of python-lockfile and suggested team maintenance

On Mar 03, 2017, at 02:03 PM, Thomas Goirand wrote: >Please consider that python-lockfile is considered deprecated upstream, >and only maintained for bugs and security. There's alternative >available, like python-oslo.concurrency. ObPlug: Or flufl.lock, albeit with a different API and other

Adopting OpenStack packages

We've talked on various lists about adopting the OpenStack packages into DPMT, and also adopting the team's standard workflows and helpers. The way the packages have been maintained in the past isn't aligned with our team practices, but Allison and I spent a little time today importing alembic

Re: PAPT and git

On Feb 23, 2017, at 10:00 AM, Jordan Justen wrote: >Looking at http://python-apps.alioth.debian.org/policy.html, it >appears that PAPT still uses svn. True. >I wanted to start working on the 'alot' PAPT package using git. On >irc, olasd let me know that the current stance is that no PAPT

Re: Moving off of git-dpm

On Feb 16, 2017, at 07:53 AM, Scott Kitterman wrote: >Which is completely separate from the question of if we want to use it as a >team. Whoever it was that suggested focusing on what (if anything) to >replace git-dpm with (post-stretch) and leave the dgit discussion for later, >I completely

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 14, 2017, at 06:30 PM, Arto Jantunen wrote: >The patch-queue branch is based on the Debian branch, not upstream. Try >merging the new upstream version to your Debian branch, and then running >gbp pq rebase. This confuses me, or I'm doing something wrong. With git-dpm the way to drop

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 14, 2017, at 05:54 PM, Brian May wrote: >Not sure how to unapply all patches. "quilt pop -a" won't work, quilt >doesn't realize the patches are applied. Yep, that does seem to be the problem. >Maybe something like the following? > >git read-tree --reset -u upstream >git reset -- debian

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 13, 2017, at 04:56 PM, Brian May wrote: >There might be errors, as I was going from memory for some of this >stuff. Thanks Brian. I did a quick review (without testing) and it looks pretty good. One section I think we should add at some point is instructions on how to manually convert

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote: >I know the discussion is leaning towards replacing usage of git-dpm >with gbp-pq. I have nothing against it but, since we are talking about >solutions for a git-centric workflow, has anyone considered the dgit- >maint-merge workflow [1]? As

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 05, 2017, at 02:07 AM, Scott Kitterman wrote: >Experimentation with a few packages to prepare for a migration and make sure >the documentation is good, is fine. We really ought to switch for real all >at once like we did for svn -> git. It's not much of a team repository >without a

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Feb 05, 2017, at 04:01 PM, Brian May wrote: >What should we call the clone page? > >PqGitPackaging??? GitPackagingPq ? Cheers, -Barry

Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Jan 29, 2017, at 09:39 AM, Brian May wrote: >I would think "gbp pq" is the most popular. I've used it on some of my non-team packages and while it takes a little getting used to for the standard git-dpm workflow, it's been mostly fine. What I'd really like to see is a page like

Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)

On Jan 23, 2017, at 02:41 AM, Scott Kitterman wrote: >Which would be horrible. single-debian-patch means that to understand the >upstream modifications, access to the packaging VCS is required. I think >that would be a huge step backwards. Agreed. -Barry

Team maintained packages and git-dpm (was Re: Team upload for python-jedi)

On Jan 22, 2017, at 03:00 PM, Dmitry Shachnev wrote: >On Sat, Jan 21, 2017 at 11:54:13AM +, Ghislain Vaillant wrote: >> "Drop DPMT from Uploaders (due to problems with multiple tarballs in >> git-dpm)" >> >> Then, the package is no longer team-maintained? > >Personally I think we could

Re: pip for stretch

On Nov 28, 2016, at 01:56 PM, Barry Warsaw wrote: >I'm starting to work on pip 9.0.1 but noticed two new dependencies. appdirs >1.4.0 we have, but distro 1.0.1 we don't. It doesn't look like there's an ITP >for that, so I'll file that bug. Okay, as soon as python-distro clears new, I'

Re: pip for stretch

On Nov 21, 2016, at 06:37 PM, Donald Stufft wrote: >As one might expect, I would prefer it if folks got 9.0.1 as quickly as >possible. In particular the feature that makes it easier for upstreams to >drop Python 2 support is one that is really only effective when people can >consider pip 9 a

Re: Binary naming for Django Related Packages

On Nov 28, 2016, at 11:11 AM, Scott Kitterman wrote: >@@ -534,6 +534,13 @@ > This requirement also applies to extension modules; binaries for all > the supported Python versions should be included in a single package. > >+ As a special exception to the `python3-' and `python-'

pip for stretch

Now that Stretch development is winding down, and I've been doing some recent maintenance on pip, I wanted to throw this out there and see if anybody has strong opinions one way or the other. I'm considering sticking with pip 8.1.2 for Stretch, even though upstream is at 9.0.1. Here's the

Re: /usr/bin/python2 shebangs

On Nov 07, 2016, at 11:44 AM, Thomas Goirand wrote: >So, I don't agree with you, and believe that gradually using >#!/usr/bin/python2 is a good approach to the transition. IMO, that's >what we should start doing as much as possible. > >If the dependencies for Python itself aren't calculated well

Re: DEP 8: Gathering Django usage analytics

On Nov 07, 2016, at 01:21 PM, Brian May wrote: >Should I ask on debian-devel? I think you should, and I'll be very interested in that discussion. Several packages in our team already apply deltas to upstream to disable certain amounts of information gathering and reporting. The most common

Re: Packaging new version of ZODB (Zope Object Database)

On Nov 03, 2016, at 08:36 PM, Julien Muchembled wrote: >I'm used to gbp. I don't know git-dpm (or I forgot after seeing I would not >like?) git-dpm is usually pretty easy, but it's really only used in a few cases, such as importing a new upstream, managing the patch stack, and tagging. We

Re: Packaging new version of ZODB (Zope Object Database)

On Nov 02, 2016, at 10:46 AM, Arnaud Fontaine wrote: >> I write to debian-python, because some of the involved packages are >> not specific to Zope. Actually, I even think that ZODB itself is not >> specific to Zope, but well, changing section of existing packages can >> be another topic.

Re: Python 4 and ‘python3’

Don't panic. :) On Nov 03, 2016, at 09:28 AM, Ben Finney wrote: >But the above post implies that pointless confusion will be directly >courted, merely because of some aesthetic objection to a two-digit >component in the version string. Those are Nick's opinions. Everyone's got one! AFAIK,

Re: Python 4 and ‘python3’ (was: /usr/bin/python2 shebangs)

On Nov 02, 2016, at 01:57 PM, Ben Finney wrote: >Donald Stufft writes: > >> /usr/bin/python3 being Python 4.x is a bit weird though > >Seriously? Who is proposing that? > >> and it’s likely that Python 4.x is not going to be another break the >> world release. > >Certainly

Re: /usr/bin/python2 shebangs

On Nov 01, 2016, at 11:34 AM, Scott Kitterman wrote: >I don't think /usr/bin/python should ever point to a python3 version. It >should be dropped when python2.7 is removed. I think the existence of >/usr/bin/python2 is a limited to a work around for a specific distros >insanity. There's no

/usr/bin/python2 shebangs

Over in #834193, a user is asking for a /usr/bin/pip2 to mirror /usr/bin/pip because some uses cases apparently prefer pip2 over pip. That seems like a reasonable request on the face of it, and easy to support. However, I thought, well why not shebang pip2 to /usr/bin/python2 because 1) it would

Re: Upstream build system, Sphinx autodoc, Python import path

On Sep 29, 2016, at 11:30 PM, Thomas Goirand wrote: >I just had a quick look to that page, not only it advises to override >the wrong dh sequence, but also it gives stupid advices for intersphinx: ObDIY: "It's a wiki". :) Cheers, -Barry

Re: can we disable the bounce kicker? Re: confirm

On Sep 11, 2016, at 09:41 AM, Sandro Tosi wrote: >now can we PLEASE stop talking about how the perfect smtp system >should work and GET BACK to discuss if we are able and want to disable >the suspend membership upon bounces (that's what the mail you receive >says, so do not nitpick on this term

Re: can we disable the bounce kicker? Re: confirm

On Sep 10, 2016, at 04:32 PM, Santiago Vila wrote: >AFAIK, Gmail does not bounce spam. It rejects messages with broken >DKIM signatures. There are a number of DKIM mitigation features in newer versions of Mailman 2 that should be investigated. I can't tell what version of Mailman this list is

Re: can we disable the bounce kicker? Re: confirm

On Sep 10, 2016, at 02:46 PM, Sandro Tosi wrote: >I'm sure i'm not the only member using gmail, which bounces spam >emails and that what causes this problem. Are you sure about that? Bouncing spam has been bad practice for a very long time. Cheers, -Barry

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

On Aug 31, 2016, at 11:31 PM, IOhannes m zmölnig (Debian/GNU) wrote: >isn't this what `gbp pull` is supposed to do? Indeed. Either this is new-ish or I missed it, but it does exactly what I want. Thanks! -Barry pgpvGDUnhftFZ.pgp Description: OpenPGP digital signature

Re: on keep providing python 2 packages

FWIW, On Aug 21, 2016, at 12:30 AM, Piotr Ożarowski wrote: >* all Python applications that support it, should use 3.X only *now* > (and do not bother with things like alternatives or "-3" suffixes / > "python3-" prefixes - at least for new packages; I'd even slowly start > removing

Re: Help for Python mock test suite needed

On Aug 17, 2016, at 01:58 PM, Andreas Tille wrote: >This exactly was my question: Is there any advise how to inject >sensible debugging code or any other strategies to find out what might >be the problem. > >> So you can use the full power of your development environment to hunt >> the problem:

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

On Aug 15, 2016, at 11:44 PM, Thomas Goirand wrote: >If we decide to use gbp-pq, in fact, we're deciding to not decide, and anyone >can use PoQ (my choice, for example). Indeed, the way to store the patches is >PoQ, and you then "gbp-pq import", modify, then "gbp-pq export" and store the

Re: BTS bot in #debian-python IRC channel

On Aug 14, 2016, at 01:01 PM, Scott Kitterman wrote: >On August 14, 2016 12:51:18 PM MDT, "Piotr Ożarowski" wrote: >>[Ben Finney, 2016-08-14] >>> Would it be a good idea to first have it running in an analogous >>> channel, ‘#debian-python-changes’? >> >>+1 (I'd move VCS

Re: BTS bot in #debian-python IRC channel

On Aug 13, 2016, at 10:48 PM, Ondrej Novy wrote: >I would like to add BTS bot to IRC channel #debian-python with same >notifications (uploads, bug reports) as in #debian-devel-changes filtered >to maintainer/uploaders: I don't *think* I'd mind getting these notifications in irc, but I guess I

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

On Aug 12, 2016, at 05:50 PM, Sergio Durigan Junior wrote: >I understand this is a matter of personal taste, but I beg to differ. I >have been using git-buildpackage for most of my non-Python packages and, >despite really small nits here and there, I think it is an awesome tool. I think there

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

Thanks for the follow up Simon. One question... On Aug 11, 2016, at 12:12 AM, Simon McVittie wrote: >gbp pq works best if all repository users stick to the dialect of DEP-3 >where all Debian-specific pseudo-headers appear at the end of the diff >(next to the Signed-off-by if any), Did you mean

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

On Aug 10, 2016, at 11:53 AM, Nikolaus Rath wrote: >I think the only way to make this less painful is to get rid of the idea >of managing patches in a VCS and use something like gitpkg. This has the >drawback source package is now *generated* from the Git repository >(i.e., you can't do git clone

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT (was: PAPT Git)

On Aug 10, 2016, at 08:49 PM, Brian May wrote: >Most of the time it works pretty well... It looked good compared with >the alternatives available at the time we made the decision. > >However this is irrelevant IMHO if it isn't being mantained. Yep. git-dpm was the best of breed at the time we

Re: pypi2deb 1.20160809 and --profile dpmt

On Aug 09, 2016, at 11:28 PM, Daniel Stender wrote: >On this occasion ... let it be me to start the discussion: let's get into Git >also for Python Apps soon. You're channeling Stefano on #debian-python: barry: I've started poking at PAPT SVN migration [15:08] :) Cheers, -Barry

Re: pep8 renamed to pycodestyle

Hi Ondrej, On Aug 08, 2016, at 11:46 AM, Ondrej Novy wrote: >what do you think about this: >https://anonscm.debian.org/cgit/python-modules/packages/pep8.git/commit/?id=655e6f631fc854c51f48f142e58bdb6b4af8494f > >With this change we can make slow transition pep8 -> pycodestyle without >breaking

Re: pep8 renamed to pycodestyle

On Aug 08, 2016, at 12:52 AM, Ondrej Novy wrote: >created (https://bugs.debian.org/833683) and uploaded :) \o/ Thanks, -Barry pgpl8ZGPKewXt.pgp Description: OpenPGP digital signature

Re: voluptuous in DPMT

On Aug 02, 2016, at 11:35 PM, Thomas Goirand wrote: >I need voluptuous for OpenStack. So unless someone needs the version in >Unstable, I prefer to not risk to break anything, and upload updates to >Experimental, just in case the new version breaks something in the older >release of OpenStack. My

Re: voluptuous in DPMT

On Aug 02, 2016, at 01:54 PM, Barry Warsaw wrote: >You won't mind if I upload 0.9.2? I'll try to merge your changes in, but >I've yet to see how easy that will be. Not too bad actually. I think I have it all prepped and ready to go in DPMT git. Cheers, -Barry pgpsyaBqHgRCL.pgp Descr

voluptuous in DPMT

Thomas, what's going on with the voluptuous package? I'm looking at starting to use it for a project and I noticed that it was pretty out of date (the current upstream is 0.9.2). So I gbp cloned the DPMT git-dpm repo and started to hack on it. The last upload appeared to be 0.8.2-1 by Robert S.

Re: [Python-modules-team] Bug#830186: sphinx: intersphinx mapping extension causes network access during package builds

On Jul 12, 2016, at 04:07 PM, Thomas Goirand wrote: >I find this not the top-noch way. Here's what I do: > >override_dh_sphinxdoc: >ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS))) > PYTHONPATH=. sphinx-build -b html doc/source \ >

Re: Removing me from Uploader field of html5lib

On Jul 04, 2016, at 04:52 PM, Olivier Berger wrote: >Unfortunately, I'm no longer able to dedicate time to help maintaining >the html5lib package. Thanks so much for your past work on it! >Thus I'm requesting that anyone uploading the next version as part of >the team, please remove me from the

Re: Python program as a command-line program (was: Python package providing both modules and an app)

On Jun 23, 2016, at 11:17 AM, Ben Finney wrote: >There isn't, AFAIK, anything portable that I can write in the shebang to >turn a command invocation of ‘./foo/bar.py’ into ‘python3 -m foo.bar’. Why not just have a file that contains only? exec python3 -m foo.bar Cheers, -Barry

Re: Best practice for adding python3 version to existing module with helper programs?

On Jun 24, 2016, at 03:30 PM, Ben Finney wrote: >Neil Muller writes: > >> I'm working on packaging the latest version of sqlobject, which adds >> supprt for python 3, and I'm unsure of how best to handle the helper >> applications that ship as part of the package.

Re: Python package providing both modules and an app

On Jun 22, 2016, at 11:25 AM, Ben Finney wrote: >This seems to be more common now that command-line invocation is >becoming even more discouraged. When the upstream documentation >recommends ‘python3 -m foo.bar’ as the primary means of invoking the >command line functionality, that really blurs

Re: pep8 renamed to pycodestyle

On Jun 21, 2016, at 10:18 AM, Piotr Ożarowski wrote: >I'd simply create new source package with new binary packages and remove >src:pep8 even from Stretch (once all rev. dependencies use new package). Yep, I'm leaning toward this, or at least creating a new source package for pycodestyle. I

pep8 renamed to pycodestyle

You might be aware that the upstream pep8 package has been renamed to pycodestyle. Both the command line and imports have changed, although not in a backward compatible way unfortunately[1]. There's a new upstream flake8 which I'm preparing in git-dpm, but it will be blocked until we decide what

Re: Intention to upload 21 packages to jessie-backports

On May 31, 2016, at 03:44 PM, Thomas Goirand wrote: >Changed-By: Barry Warsaw <ba...@debian.org> >Source: python-webob I am at Pycon US this week (anybody else?). Please feel free to do what you need! Cheers, -Barry pgp4htO8yJedU.pgp Description: OpenPGP digital signature

PyconUS 2016

Pycon 2016 starts in one week in Portland OR, USA. I'll be there for the duration (flying in late Friday evening). Who else is coming? We should definitely have a Debian Python BOF, and perhaps a keysigning if there isn't one organized for the larger Python community. I'm sure we can find fun

Re: pypy pakages

On May 10, 2016, at 09:56 PM, Tristan Seligmann wrote: >I think it would be great if we could get performance-sensitive applications >running on PyPy instead of CPython, but of course this requires the whole >dependency graph to have pypy-* packages built. That might be a good approach to

Re: pypy pakages

On May 10, 2016, at 07:23 PM, Michael Fladischer wrote: >is there a specific reason why there are so few pypy-* packages in the >archive? Is it just a lack of interest or are any practical reasons not >to have them? I don't think there are too many practical reasons other than every package that

Re: [Python-modules-team] [Python-modules-commits] [mpmath] 01/01: d/copyright: Changed licence shortname BSD -> BSD-3-clause

On Apr 30, 2016, at 07:21 PM, Ondrej Novy wrote: >announced before: >http://lists.alioth.debian.org/pipermail/python-modules-team/2016-March/030256.html Thanks! I must have missed it, but you did the right thing. -Barry PS: why do we have two mailing lists?! :( :( pgpnvPRcM4YYn.pgp

Re: Test suite in github but missing from pypi tarballs

On Apr 21, 2016, at 04:52 PM, Thomas Goirand wrote: >It's best that the test suite goes within the project. So if project is >called foo, then best is to get the test folder in foo/tests. This way, >you don't even need to fix the MANIFEST.in. +1 - as an upstream I always do this because I like

Re: Test suite in github but missing from pypi tarballs

On Apr 21, 2016, at 02:54 PM, Tristan Seligmann wrote: >With my upstream developer hat on: source packages on PyPI are meant for >end users to install via pip. They often include generated artifacts, and >don't include things that aren't intended for installation via pip (tests >being just one of

Re: remember to git pull

On Apr 17, 2016, at 06:36 PM, Brian May wrote: >(or even better, use the quick-update script instead) quick-update script? Oh, and +1 for the recommendation! I'd just add to also be sure that you commit and push your changes. ;) I've had one or two cases where the repo doesn't match the

Re: CPython hash randomization makes some Python packages unreproducible

On Apr 09, 2016, at 08:11 PM, Julien Cristau wrote: >FWIW I think that's a bad idea. A number of packages run their test >suite at build time, and running the tests with hash randomization >enabled seems to me like something we shouldn't give up. Completely agreed. Although we're in the long

Re: Packaging Grip

On Apr 06, 2016, at 11:48 PM, Scott Kitterman wrote: >In my opinion either can be correct depending on the primary purpose of the >package. I think that's true; take it on a case-by-case basis. In general, I like having a separate binary package for the /usr/bin script because it can be more

Re: dropping top patch with git-dpm

On Apr 04, 2016, at 05:33 PM, Brian May wrote: >Ok, so as I expected, integrating a new upstream release resolved this >issue for me. git-dpm import-new-upstream left me in the patched >directory, and I was able to drop the last patch and then run git-dpm >update-patches. When it works, it's

Re: running tests against installed version of package

On Mar 26, 2016, at 01:49 PM, Brian May wrote: >Barry Warsaw <ba...@debian.org> writes: > >> In some cases, I've just taken to adding DEP-8 tests for those. > >Do you have an example I can look at? Hi Brian. Take a look at tox for example. Cheers, -Barry

Re: running tests against installed version of package

On Mar 25, 2016, at 06:17 PM, Brian May wrote: >However I have a package where the tests require the entry points from >setup.py to be configured, the tests fail without this. > >So what is the appropriate way to modify debian/rules to get the tests >to run from the installed version with the

Re: Packaging dependencies for mailman3-hyperkitty

On Mar 25, 2016, at 01:02 PM, Paul Wise wrote: >Does HyperKitty depend on mailman3 or just enhance it by providing an >archive web interface? Although greatly enhanced by it, Mailman 3 (core) doesn't require HyperKitty. HK isn't currently useful on its own though. Cheers, -Barry

Re: Use Python3 where possible

Probably no surprise, but I agree with everything Matthias said. On Mar 15, 2016, at 11:20 AM, Matthias Klose wrote: >I would like to come up with a recommendation that if a python module ships >scripts, Python3 is used for these scripts, and the Python2 version of these >scripts should be

Re: Is pristine-tar failing just for me?

On Mar 09, 2016, at 11:21 AM, Nikolaus Rath wrote: >Whenever I use pristine-tar, I'm getting the following warning: > >| warning: pristine-gz cannot reproduce build of [whatever].orig.tar.gz; >storing 85% size diff in delta >| (Please consider filing a bug report so the delta size can be

Re: Updating python-django-tagging

On Mar 07, 2016, at 10:24 AM, Brian May wrote: >I really like the work flow of git-dpm. Think it is much better then >gbp-pq, which IIRC stores and distributes the patch files in git. > >Shame it isn't better maintained. As a result, seems it is very easy to >get it in a confused state (e.g. by

Re: Updating python-django-tagging

On Mar 06, 2016, at 01:12 PM, Christopher Baines wrote: >However, git-dpm keeps complaining in different ways when I try to do >this (and I have tried a few different ways). I think the source of the >issues I am having could be that the debian/.git-dpm file is out of sync >with the rest of the

Re: Using 'pyvenv' or 'python3 -m venv' on unstable

On Mar 02, 2016, at 11:40 AM, Florent Rougon wrote: >Sorry for linking to my own bug report, but am I the only one affected >by bug #815864? Since the fix for this is in python3.5, I've already provided a patch to Matthias. I wanted to get his feedback about one particular point of the patch,

Re: nose2 reverse dependancies

On Mar 01, 2016, at 11:02 PM, Mattia Rizzolo wrote: >FYI, I don't know of a nice way to build a dependency graph, like sometimes I >see somewhere, with graphiz That's a tool I'd sometimes love to have too. Cheers, -Barry pgpSD9s_Vutxe.pgp Description: OpenPGP digital signature

Re: Autopkgtest smoke test for Python libraries

On Mar 01, 2016, at 06:10 PM, Martin Pitt wrote: >You could use it for that purpose indeed, but that's not really what >it is intended for. The idea is that the generic tests apply to all >packages of a particular type, so you can change them centrally >instead of having to modify and upload

Re: Autopkgtest smoke test for Python libraries

On Mar 01, 2016, at 09:05 AM, Martin Pitt wrote: >Very nice! There's precedent for Perl, Ruby and DKMS packages which >have a fairly standard way to run the upstream test suite. For Python >there are some conventions, like "./setup.py test" or running >nosetests, maybe it's worth experimenting

Re: Python Policy: Things to consider for Stretch

On Feb 16, 2016, at 11:54 AM, Paul Wise wrote: >I always thought it strange to put site- in /usr/local since >/usr/local already implies site/system-wide packages. Same for dist- >since /usr already implies distribution packages. For as long as I can remember, a from-source 'configure && make &&

Re: Python Policy: Things to consider for Stretch

On Feb 15, 2016, at 07:42 PM, Barry Warsaw wrote: >I don't remember exactly why we called it 'site-packages', but I believe it >was an evolution from the earlier ni.py module, which was where dotted module >paths first showed up in Python. And which had a 'site-python' directory, which

Re: [Python-modules-team] Git-dpm help for tweepy

On Feb 11, 2016, at 09:09 AM, Ross Gammon wrote: >I was working last night on fixing the RC bug for tweepy, but got myself >in a muddle with git-dpm. Yep, git-dpm will do this some times. :/ >Tweepy is currently 3.4.0 & 3.5.0 is a new available release. I cloned, >fixed the bug (just disabling

  1   2   3   4   5   6   7   8   >