On Jun 10, 2011, at 12:51 PM, Steve Langasek wrote:
>Binary package names, separated by spaces. (Deciphered from
>poring over /usr/share/cdbs/1/class/python-vars.mk.)
>
>> (I will update the wiki pages.)
>
>Thanks!
Done! Thanks.
-Barry
signature.asc
Description: PGP signature
On Jun 10, 2011, at 09:48 PM, Eike Nicklas wrote:
>Then 'import foo' fails if '/usr/share/foo/foo' is not explicitly added
>to pythonpath (that was the idea of having the module private
>in the first place ;-) )
Ah, yeah. Y'know, I am personally not a fan of private modules anyway :).
Note too i
On Jun 10, 2011, at 09:01 PM, Eike Nicklas wrote:
>I just tried to package an application using a private module. In this
>case, the name of the script starting the application and the module
>have the same name.
Is the script private too? Wouldn't that be better installed in /usr/bin/foo?
-Bar
On Jun 10, 2011, at 10:09 AM, Steve Langasek wrote:
>Did you try with:
>
> DEB_PYTHON2_MODULE_PACKAGES = ubuntu-system-service
Bingo!
>This is a list of Debian package names, not python package names. If cdbs
>isn't explicitly told about the packages it should run on, it doesn't run
>setup.py
Yesterday, I sent this message to ubuntu-devel:
https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033440.html
and created this wiki page:
https://wiki.ubuntu.com/BarryWarsaw/PythonHelpers
These outline the dh_python2 conversions we plan to do in Ubuntu, but of
course, we want to coordina
I'm having some trouble with the instructions on converting from
python-central to dh_python2 while retaining cdbs.
http://wiki.debian.org/Python/PyCentral2DhPython2
I see that Steve just added another hint, but that didn't help me much. I'm
proofing the instructions with lp:ubuntu-system-servic
On Jun 09, 2011, at 05:05 PM, Bernd Zeimetz wrote:
>On 06/07/2011 11:39 PM, Piotr Ożarowski wrote:
>> but pysupport is not deprecated so you cannot file bugs and ask people
>> to convert now
>
>Can we please do so for Wheezy?
+1
What is the process for deprecating python-support? Who makes that
On Jun 07, 2011, at 11:39 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2011-06-07]
>> There is also a wiki page about how to convert from pysupport to dhpy2:
>>
>> http://wiki.debian.org/Python/PythonSupportToDHPython2
>>
>> but there's no similar
Hi all,
We have a list of packages in Debian which need conversion from pycentral to
dhpy2:
http://tinyurl.com/3px5rwz
this is linked from
http://wiki.debian.org/Python/PyCentral2DhPython2
There is also a wiki page about how to convert from pysupport to dhpy2:
http://wiki.debian.o
On May 15, 2011, at 11:57 PM, Scott Kitterman wrote:
>> http://pkgme.net/
>
>Which is rather less complete for Python packaging than stdeb and I'd prefer
>we don't recommend.
Perhaps, but I think it's a good project to contribute to if you want to make
package easier for people (not just for Pyt
On May 15, 2011, at 10:40 PM, Piotr Ożarowski wrote:
>[Janne Snabb, 2011-05-13]
>> I assume that "pypi-install" is the most sensible way to install
>> Python packages which have not been packaged for Debian.
>
>true
>
>[...]
>> How do I tell "pypi-install" to install packages for python3? By
>> d
Hi folks,
I spent about a day and a half tracking down a problem with virtualenv. As of
virtualenv 1.6 (which is in wheezy), it *should* be possible to use python3 as
a -p target. This fails because the way virtualenv re-invokes itself does not
play nicely with our symlink farm.
All the gory de
On May 02, 2011, at 03:17 PM, Jakub Wilk wrote:
>* Bernd Zeimetz , 2011-05-02, 14:58:
>I would prefer if we could make the transition a release goal.
Would you be up for writing it up and proposing it as such? I support
>>>the idea.
>>>Uhum, yes, we need more people laughing at us.
>>
On Apr 28, 2011, at 02:41 PM, Bernd Zeimetz wrote:
>I can't see any problemswith pysupport here -
>http://wiki.debian.org/Python/PythonSupportToDHPython2
>The migration is well documented and if there is something to fix in
>-support to make a migration happen, I'm happy to upload it.
I thought n
On Apr 26, 2011, at 10:09 PM, Luca Falavigna wrote:
>Il 26/04/2011 21:28, Barry Warsaw ha scritto:
>> Anyway, I think it's a big job to do all the conversions, but I've already
>> done a number of them, so I think I can be helpful filing bugs and submitting
>> patc
Hi everyone,
One of the things I am planning on working on during the next Ubuntu cycle is
the transition to dh_python2. I think there are two parts to this:
* Uncontroversial: python-central -> dh_python2
* (Perhaps?) controversial: python-support -> dh_python2
I hope I'm not offending anyone
On Apr 22, 2011, at 08:55 PM, Stefano Rivera wrote:
>Hi Barry (2011.04.22_03:28:12_+0200)
>> When I click on 'last log' for say ia64, I just see a build log with
>> no failures in it. So why does it show up on the main page with
>> straight red-X's?
>
>The transition tracker is just tracking the
On Apr 15, 2011, at 10:17 AM, Scott Kitterman wrote:
>I just uploaded python-defaults to Unstable that drops Python 2.5 and adds
>Python 2.7 as supports Python versions. Python-central, distribute, and
>python-stdlib-extensions are already updated to support Python 2.7. The
>planned python-suppo
On Apr 03, 2011, at 08:53 PM, Scott Kitterman wrote:
>The release team has ack'ed the python3 transition (See #617272). I'll
>upload a new python3-defaults shortly. Once that's in we'll start with the
>required sourceful uploads and binNMUs. Over the next few days, please keep
>an eye on any pyt
On Mar 30, 2011, at 04:02 PM, Piotr Ożarowski wrote:
>FYI: I plan to upload python-sphinx, python-defaults (without Python
>2.5, with Python 2.7) and python3-defaults (with Python 3.2 instead of
>Python 3.2) tomorrow. Please report bug against tech-ctte and CC me if
>you think it's not a good idea
On Mar 23, 2011, at 01:41 PM, Francesca Ciceri wrote:
>< liw> how about something like dh-make-perl but for python's pypi?
>i.e., take a package from pypi (the python package inventory) and
>make a rudimentary debian package out of it, automatically?
I think this is a great idea, and as Zygmunt
On Mar 10, 2011, at 10:53 PM, Jakub Wilk wrote:
>* Ludovic Rousseau , 2011-03-10, 21:41:
My package provides a binary extension so must be compiled for each
>>>supported Python versions: 2.5 and 2.6 as of now.
>>>
>>>...your new debian/rules does *not* compile extensions for all >>support
On Mar 10, 2011, at 04:12 PM, Josselin Mouette wrote:
>Le jeudi 10 mars 2011 à 09:00 -0500, Scott Kitterman a écrit :
>> The upstream Python position is (I'll paraphrase), "There will not be
>> a Python 2.8. If there is a new feature release of Python 2 it will be
>> because someone forked it - it
On Mar 10, 2011, at 12:15 PM, Raphael Hertzog wrote:
>On Thu, 10 Mar 2011, Piotr Ożarowski wrote:
>> seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹,
>> we don't have to worry about 2.X transitions when 2.7 will become the
>> only supported one. If you don't like Breaks, I wi
On Mar 09, 2011, at 10:57 AM, Yaroslav Halchenko wrote:
>On Mon, 07 Mar 2011, Barry Warsaw wrote:
>> >Because none is as advanced as git is.
>> Are there specific git features that you think the team would want to use,
>> that are missing from the other dvcs?
>
>ma
On Mar 07, 2011, at 08:18 AM, Bernd Zeimetz wrote:
>On 03/06/2011 07:33 PM, Barry Warsaw wrote:
>> On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote:
>>
>>> Do the 2 VCDs you mentioned have clear advantage that make then
>>> preferible to git except being Py
On Mar 06, 2011, at 08:55 PM, Arto Jantunen wrote:
>I used to choose tools based on the language they are implemented in, I
>justified it with the old "it needs to be in a language I know/like in
>case I need to modify it or fix bugs in it" excuse. Since then I learned
>my lesson and, unless I'm s
On Mar 07, 2011, at 08:28 AM, Robert Collins wrote:
>For clarity, the thing I'm referring to is the ability to commit
>directly to a stacked branch - which I think is equivalent to the
>partial limitation you're referencing. I've just checked in #bzr, and
>that is in 2.3.0, which has been out for
On Mar 06, 2011, at 05:53 PM, Yaroslav Halchenko wrote:
>
>On Sun, 06 Mar 2011, Piotr Ożarowski wrote:
>> > git diff ... | patch; git commit -m 'Merged blah bleh into blue'
>> hint: git merge --squash
>
>ah, evil evil evil git developers for allowing such a thing! I never
>used it ;-)
I've heard
On Mar 07, 2011, at 01:56 AM, Andrey Rahmatullin wrote:
>On Sun, Mar 06, 2011 at 01:33:45PM -0500, Barry Warsaw wrote:
>> Let me turn that around: why would you *not* want to use a Python based dVCS?
>>
>Because the language of a tool shouldn't usually matter at all?
Un
On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote:
>Do the 2 VCDs you mentioned have clear advantage that make then
>preferible to git except being Python-based? If so, I think it's a
>quite weak reason.
Let me turn that around: why would you *not* want to use a Python based dVCS?
One reason coul
On Mar 06, 2011, at 12:12 PM, Vincent Bernat wrote:
>There was some discussions about switching from SVN to git. I don't
>remember everything but a major blocker was that it is not possible to
>checkout a subtree with git and managing a lot of git repositories will
>make it difficult to do
On Mar 04, 2011, at 02:15 PM, Scott Kitterman wrote:
>Currently Python policy says:
>
>1.4.2. Interpreter Location
>---
>
> The preferred specification for the Python interpreter is
> `/usr/bin/python' or `/usr/bin/python.'. This ensures that a
> Debian install
So I know many of you are on python-dev, so you might have seen this come up,
but traffic there can be pretty heavy at times.
Upstream Python recommends that the shebang line for scripts should be
#!/usr/bin/env python
however, this should only apply to *developer* packages, not operating system
Hi Sandro. Of course, as you know I do not (yet :) have upload rights, but I
do want to help move this along in any way possible. My schedule will be
insane until after the Python conference though, and I sure could use some
guidance in being more productive in Debian.
(BTW, are any debian-pytho
On Feb 23, 2011, at 11:11 PM, Andrey Rahmatullin wrote:
>On Tue, Feb 22, 2011 at 09:47:20AM -0500, Barry Warsaw wrote:
>> runs the tests against all available Python2
>> interpreters. (I need to enable Python3 at some point.)
>Here is a problem: all test dependencie
On Feb 23, 2011, at 06:54 PM, Bernd Zeimetz wrote:
>On 02/22/2011 05:54 PM, Andrey Rahmatullin wrote:
>> On Tue, Feb 22, 2011 at 11:17:47AM -0500, Scott Kitterman wrote:
> It would be nice if dh auto-detected a setup.py (and/or missing Makefile)
> and didn't run 'make test' in that case, s
On Feb 22, 2011, at 09:55 PM, Andrey Rahmatullin wrote:
>On Tue, Feb 22, 2011 at 09:47:20AM -0500, Barry Warsaw wrote:
>> It would be nice if dh auto-detected a setup.py (and/or missing Makefile)
>> and didn't run 'make test' in that case, so that the override_dh
On Feb 22, 2011, at 11:27 PM, Andrey Rahmatullin wrote:
>On Tue, Feb 22, 2011 at 07:23:51PM +0100, Vincent Bernat wrote:
>> I wasn't aware of the existence of a test target.
>It's a setuptools feature if I understand correctly
>(setuptools.command.test) and it needs specific test* arguments t
On Feb 22, 2011, at 11:17 AM, Scott Kitterman wrote:
>On Tuesday, February 22, 2011 09:58:36 am Bernd Zeimetz wrote:
>> On 02/22/2011 03:47 PM, Barry Warsaw wrote:
>> > It would be nice if dh auto-detected a setup.py (and/or missing Makefile)
>> > and didn't run &
On Feb 22, 2011, at 03:58 PM, Bernd Zeimetz wrote:
>On 02/22/2011 03:47 PM, Barry Warsaw wrote:
>
>> It would be nice if dh auto-detected a setup.py (and/or missing Makefile)
>> and didn't run 'make test' in that case, so that the override_dh_auto_test
>> wa
On Feb 22, 2011, at 03:51 PM, Andrey Rahmatullin wrote:
>In many cases $PYTHON setup.py test (for all supported $PYTHON's) is
>enough to run the tests and any errors mean that something is wrong with
>the environment (provided the tests are correct).
>
>Shouldn't we have some written recommendatio
On Feb 07, 2011, at 10:27 AM, Piotr Ożarowski wrote:
>We plan to upload new python-defaults to unstable really soon now
>(once python2.7 will be available for all architectures in unstable).
+1
>Instead of Python 2.5, it will list Python 2.7 as supported
>(default=2.6; supported=2.6,2.7).
>
>Onc
On Jan 21, 2011, at 05:11 AM, Andrey Rahmatullin wrote:
>On Fri, Jan 21, 2011 at 01:08:34AM +0100, Jakub Wilk wrote:
>> >How about supporting both python (default being Python 2.7) and python3
>> >(default being Python 3.x, x=2 in Wheezy?) forever as two separate
>> >languages?
>> That's the plan.
On Jan 20, 2011, at 11:16 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2011-01-20]
>> If I may make a radical suggestion though: what do you think about making
>> Python 3 the default for Wheezy?
>
>over my dead body ;-P
Okay, then Wheezy+1 :)
-Barry
signature.asc
Description: PGP signature
On Jan 20, 2011, at 10:31 PM, Luca Falavigna wrote:
>Today there was a little discussion in #debian-python about Python plans
>as soon as wheezy cycle starts (as you know, that will probably happen
>on early february, see [0]), let's discuss it here to give people a
>chance to express their opinio
On Jan 20, 2011, at 08:55 PM, Michael Fladischer wrote:
>Barry Warsaw, 2011-01-20 20:26:
>> On Jan 20, 2011, at 07:22 PM, Sandro Tosi wrote:
>>> Would it make sense to rename upstream module to importlib3 (to recall
>>> the fact it's a backport from py3k) an
On Jan 20, 2011, at 07:22 PM, Sandro Tosi wrote:
>Attention: stupid question coming.
Not at all!
>Would it make sense to rename upstream module to importlib3 (to recall
>the fact it's a backport from py3k) and so it would importable also in
>2.7 along with the stdlib 'importlib' module?
I think
On Jan 20, 2011, at 05:20 PM, Éric Araujo wrote:
>This is not relevant to the question about the toolchain that you were
>asking, but I’d like to point out that importlib in 2.7 is only a subset
>of the version in 3.1 (precisely, importlib.import_module only), so
>packaging a full backport of impo
On Jan 13, 2011, at 04:08 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2011-01-13]
>> Actually, I think dh_python2 *is* better because the symlinks aren't created
>> at install time, but instead are included in the package.
>
>we're talking about private modules here
On Jan 13, 2011, at 03:33 PM, Piotr Ożarowski wrote:
>[Jakub Wilk, 2011-01-13]
>> Out of curiosity, how is dh_python2 better thant python-support for
>> Python applications? (It's a 97% honest question!)
>
>It's not better¹ and it's not worse. I asked to consider it for NEW
>package because I wa
On Jan 06, 2011, at 12:45 PM, Robert Collins wrote:
>I'm not trying to do this in a hidden way though? Why do you think
>that that is the case?
Sorry, I meant "automatic".
-Barry
signature.asc
Description: PGP signature
On Jan 05, 2011, at 11:40 PM, Piotr Ożarowski wrote:
>IMHO installing two versions of the same (public) Python module should
>be simply forbidden in policy. For one simple reason: if module foo uses
>bar in version 1 and spam uses bar in version 2, imagine what will
>happen with egg which uses bot
On Jan 04, 2011, at 07:30 AM, Robert Collins wrote:
>It really does look like having better upstream facilities would make
>this a no-brainer for us; what I'd like to achieve though is something
>that /works/ for the existing python platform - for 2.7 which will be
>around a good long time, and th
On Jan 04, 2011, at 07:13 PM, Vincent Bernat wrote:
>My problem is in python-cerealizer:
>
>,
>| # Cerealizer
>| # Copyright (C) 2005-2008 Jean-Baptiste LAMY
>| # Copyright (C) 2008 Peter Eckersley
>| #
>| # This program is free software.
>| # It is available under the Python licence.
>`
>
Robert brings this up every time I see him. :) I'm glad we're still talking
about it; while I'm sympathetic to the use case, it just seems like a problem
fraught with difficulties.
One question is whether the entire Debian packaging system knows that there
are multiple versions of a package availa
On Dec 22, 2010, at 08:49 PM, Luca Falavigna wrote:
>Il 22/12/2010 20:18, Barry Warsaw ha scritto:
>> I'd be willing to help out with these on both the Debian and Ubuntu sides,
>> though I do not yet have upload rights in either distro.
>
>It's not a problem, I'
On Dec 22, 2010, at 08:10 PM, Luca Falavigna wrote:
>These should be handled in stack, as they are all related to one
>another, so if you are interested in at least one, you should really
>consider to take care of all of them. I'm also CCing James (who is
>actually listed as co-maintainer and he's
On Nov 23, 2010, at 12:28 AM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2010-11-22]
>> What specifically does dh need to do better now, after you cdbs patch?
>
>it needs someone who likes to program in "you can do it in 1000+1 ways"
>(aka Perl) ;-), see bugs 596807 and 59
On Nov 22, 2010, at 09:05 PM, Jakub Wilk wrote:
>* Barry Warsaw , 2010-11-22, 14:51:
>>AFAICT, dh_python2 handles namespace packages for you.
>
>AFAICT it doesn't (by design). Which is yet another reason to stick with
>python-support.
I think it does though...
% apt-file
On Nov 21, 2010, at 01:52 AM, Piotr Ożarowski wrote:
>CDBS is not that popular among maintainers of Python related packages
>(dh rules!) so I wrote python3-distutils.mk (based on
>python-distutils.mk) for it hoping that dh lovers will now do their best
>to support Python 3 better than CDBS does wi
On Nov 22, 2010, at 10:54 AM, Piotr Ożarowski wrote:
>I wanted to add flaskext/__init__.py file to python-flask binary package
>yesterday and I realized it will require to add too many lines to my
>tiny debian/rules file so... I implemented pyinstall feature in
>dh_python2 instead (see debpython/t
On Nov 08, 2010, at 03:30 PM, Clint Byrum wrote:
>https://launchpad.net/pkgme
>
>There's even code already:
>
>https://code.launchpad.net/~pkgme-committers/pkgme/trunk
Ah, of course, thanks!
-Barry
signature.asc
Description: PGP signature
On Nov 08, 2010, at 04:16 PM, Yaroslav Halchenko wrote:
>there is also py2dsc from python-stdeb if we go for automation (I've
>not tried it yet though :-/)
While I'm a big fan of python-stdeb, I should also point out that at UDS-N,
James Westby laid out a plan and an architecture for a tool to m
On Nov 08, 2010, at 02:53 PM, Paul Elliott wrote:
>Sorry if this is a faq, but are there any hellow world
>debian sample packages that could be used as a starting point?
I have a very simple extension module that I use to debug Python build
experiments. I could debianize it and make it available
On Nov 05, 2010, at 09:46 PM, Stefano Rivera wrote:
>#!/usr/bin/make -f
>%:
> dh $@
[...]
>
>For new packages, you should probably consider using dh_python2 instead
>of python-support. The eventual plan is to migrate all Python packages
>to it.
Which should be as easy as adding "--with pyth
On Oct 22, 2010, at 07:52 PM, Julian Andres Klode wrote:
>Tell that the Arch people:
>http://www.archlinux.org/news/python-is-now-python-3/
>
>Yep, they switched /usr/bin/python to Python 3.X
I heard that Gentoo has done it too, but I have not verified that.
-Barry
signature.asc
Descripti
On Oct 18, 2010, at 05:33 PM, Josselin Mouette wrote:
>If you mean “port all the scripts and applications of the default
>installation from python to python3”, then that’s a goal that could be
>achieved for wheezy.
Especially if we work with other Python porters:
http://mail.python.org/mailman/l
On Oct 21, 2010, at 06:50 PM, Jakub Wilk wrote:
>If you care only about byte-compilation, installing a package is
>overkill. It's way easier and faster just to unpack the .deb (dpkg-deb -x)
>and run `python2.7 -m compileall /path/to/unpacked/stuff`.
Nice tip, thanks. I've added it to the wiki pa
Ultimately of course we all want to land on Python 3. In conversation with
Toshio Kuratomi and David Malcolm of the Fedora project, we feel that it's in
all of our best interest to pool our resources. I think the distros are on
the front lines of this transition, and working together across the d
On Oct 21, 2010, at 09:15 AM, Luca Falavigna wrote:
>Il 21/10/2010 1.30, Barry Warsaw ha scritto:
>> * Python 2.7 compatibility
>>
>> We need to check both build and installation (i.e. for pure Python packages)
>> compatibility for 2.7.
>
>We should analyze whic
On Oct 21, 2010, at 06:35 AM, Jakub Wilk wrote:
>* Barry Warsaw , 2010-10-20, 19:30:
>>We need to check both build and installation (i.e. for pure Python package
>s)
>>compatibility for 2.7.
>
>What is so special about pure-Python packages?
I mistyped. I meant
Python 2.7 is now supported in experimental. Along with the opening of Ubuntu
11.04 for development, it's time to revisit our transition to Python 2.7.
It's something I'm keen on doing, and committed to working on.
It's imperative to me that we do this transition so that both Debian and
Ubuntu ca
Hi folks. Most of you probably have seen this, but just in case, I hope it's
okay to forward to this list. It would be awesome have a nice representation
of debian-python at the conference.
Some talk ideas:
* explaining to folks how Python is delivered on Debian. This would include
things
On Sep 25, 2010, at 01:22 PM, Paul Wise wrote:
>On Mon, Aug 23, 2010 at 8:17 PM, Barry Warsaw wrote:
>
>> My guess is that you'd get a lot of push back from folks in
>> python-dev. Won't a change like this have the potential to produce
>> confusing, wrong, or h
On Sep 21, 2010, at 03:02 PM, Clint Byrum wrote:
>In the java world, they use maven because it handles this for them.
>They create a maven spec file that says "I need libX, libY, and
>libZ (v1.1)". maven, during the build, goes out and finds libX and
>libY's latest versions, then finds the closest
On Sep 21, 2010, at 10:30 AM, Piotr Ożarowski wrote:
>[Robert Collins, 2010-09-20]
>> Path to a solution: use an API marker analgous to the ABI markers C
>> libraries have. Incompatible changes to a package bump the package
>> *name*. e.g.
>> python-zope.publication2.3 to python-zope.publication2.
: Fri, 20 Aug 2010 09:22:20 +1200
From: Robert Collins
To: Barry Warsaw
Subject: Python packaging, dependencies, upstream facilities
So, I'm going to give you a use case that debian packages suck at for
python (they don't for C) and how I see a path-to-a-solution.
If you were to make
On Sep 02, 2010, at 08:43 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2010-09-02]
>> What do you think about merging my changes to make Python 2.7 a
>> supported version in experimental, either before or after squeeze is
>> released? I guess once squeeze is out, it
On Sep 01, 2010, at 10:17 AM, Paul Wise wrote:
>On Wed, Sep 1, 2010 at 6:33 AM, Marian Sigler
>wrote:
>
>>> Given how much work is required to change the default Python, does
>>> it make sense to just skip Python 2.6 and use 2.7 as the default
>>> Python version in Squeeze?
>> What has emerged he
On Sep 01, 2010, at 12:33 AM, Marian Sigler wrote:
>> Given how much work is required to change the default Python, does it
>> make sense to just skip Python 2.6 and use 2.7 as the default Python
>> version in Squeeze?
>What has emerged here? I see that it won't be the default, but will it
>be at
On Aug 22, 2010, at 10:16 PM, Floris Bruynooghe wrote:
>Using the standard warnings module this would only happen once for
>each python script. This sounds like the more sensible behaviour, but
>it sounds like it should be fixed upstream so that the unguarded
>setlocale just shows this behaviour.
On Aug 14, 2010, at 10:11 PM, Piotr Ożarowski wrote:
>Summary of discussions in the Python BoF meet at DebConf10
Thanks for the update. Being not far from my back yard, I was hoping to make
it but it fell within family summer vacation.
>Squeeze will ship with Python 2.5, 2.6 (as default) and 3.
On Aug 04, 2010, at 03:21 PM, Jakub Wilk wrote:
>* Paul Wise , 2010-08-04, 08:31:
>>> There are pychecker, pyflakes, and pylint in Debian.
>>> This specific case raises a warning in pylint, if I'm not mistaken.
>>
>>Thanks for the info, I've added these package names to the
>>DebianMentorsNet wiki
On Jul 27, 2010, at 12:33 AM, Jakub Wilk wrote:
>In sid there are two packages with python2.7-specific bytecompilation
>errors: mgltools-viewerframework and python-jaxml. Both packages do
>something like:
>
>import sys
>sys.__debug__ = something
>
>which is a syntax error in Python 2.7.
This one'
On Jul 30, 2010, at 07:55 AM, Clint Byrum wrote:
>[bump]
>
>Anybody?
I have little street cred to speak for DPMT, but I would be hesitant about
it. I personally have little Ruby or Lua experience and wouldn't know how to
fix problems in those bindings.
OTOH, I don't have a better suggestion. :(
On Jul 30, 2010, at 11:16 AM, Nicolas Chauvat wrote:
>On Thu, Jul 29, 2010 at 11:23:05AM -0400, Barry Warsaw wrote:
>> True. I like separating my tests into submodules, and I don't
>> personally like in-docstring doctests, so I'm biased toward those
>> decisions.
&
On Jul 29, 2010, at 03:35 PM, Jakub Wilk wrote:
>* Jakub Wilk , 2010-07-28, 18:35:
>>looking at sip4-qt3 build log, even the PPA version provides only
>>>modules for 2.6, which looks like a bug in sip4-qt3.
>
>Actually, it's python-defaults in toolchain2.7 PPA, which does not
>support python2.7. Y
On Jul 28, 2010, at 12:23 AM, Sandro Tosi wrote:
>anyhow, since I'm at it: please don't force ANY testing tool; I kinda
>like unittest2, and it's available in python2.7 stdlib, and it's also
>backported to 2.4-2.6 (and even packaged for debian), and I don't want
>to be forced to use nose for my up
On Jul 27, 2010, at 05:56 PM, Yaroslav Halchenko wrote:
>On Thu, 22 Jul 2010, Barry Warsaw wrote:
>> In my copious spare time , I'm working on code, documentation,
>> and infrastructure to make this the preferred way of testing Python
>> modules and applications. You do
On Jul 27, 2010, at 09:48 PM, Yaroslav Halchenko wrote:
>well, both "setup.py test" and "module.test()" sound like reasonable
>interfaces to adhere to.
Yes, especially if 'python -m module.test' were an available command line
interface. The former could be promoted for in-development testing and
Hi Jakub,
Thanks very much for looking at these. I have some dumb questions. :)
On Jul 26, 2010, at 10:54 PM, Jakub Wilk wrote:
>* Barry Warsaw , 2010-07-26, 15:38:
>>https://launchpad.net/~pythoneers/+archive/py27stack4/+packages
>>
>>As you can see there are a fe
Having just returned from a platform rally in Prague, I thought I would update
folks on the progress of enabling Python 2.7 as a supported -- but not default
-- Python in Ubuntu Maverick (what will be 10.10). I'd also like to take this
opportunity to solicit help in getting us to the point where w
On Jul 15, 2010, at 06:55 PM, Markus Gattol wrote:
> Barry> This means that if you install Python from-source, as many
> Barry> Python developers do through the default cmmi build, and system
> Barry> administrators do achieve Python builds isolated from critical
> Barry> system resources, you cou
On Jul 22, 2010, at 10:00 AM, Yaroslav Halchenko wrote:
>
>On Thu, 22 Jul 2010, Barry Warsaw wrote:
>> >But assuming that in longer run we agree on how we invoke
>> >unittesting for Python modules we ship[...]
>
>> I propose this be spelled: 'python setup.py
On Jul 21, 2010, at 04:17 PM, Yaroslav Halchenko wrote:
>But assuming that in longer run we agree on how we invoke unittesting for
>Python modules we ship[...]
I propose this be spelled: 'python setup.py test'.
In my copious spare time , I'm working on code, documentation, and
infrastructure to
On Jul 14, 2010, at 10:56 AM, Suno Ano wrote:
>Yes, that is a common question people have when they want to know how
>exactly things are handled in Debian. It was the same for me so I
>created
>
>http://www.markus-gattol.name/ws/python.html#why_has_debian_dist-packages_directories
Hi Suno. Thank
On Jul 13, 2010, at 11:05 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2010-07-13]
>> * http://wiki.debian.org/DebianPython
>> * http://wiki.debian.org/Python
>
>I removed some really old pages with "Python" in the URL
Nice!
>What do you think about renaming al
On Jul 13, 2010, at 10:43 AM, Asheesh Laroia wrote:
>On Mon, 12 Jul 2010, Barry Warsaw wrote:
>
>> We had a report in upstream Python from a user who was trying to find
>> information about dist-packages. He did a Google search and didn't
>> find any definitive
We had a report in upstream Python from a user who was trying to find
information about dist-packages. He did a Google search and didn't find any
definitive official explanation of this Debuntuism. His suggestion was to add
a note to the official Python documentation, but that doesn't seem quite
701 - 800 of 859 matches
Mail list logo
