-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 11, 2008, at 3:43 AM, Matthias Klose wrote:
Currently Debian's python has /usr/local/lib/python2.x/site-packages
in sys.path allowing for installation of local modules. Barry did
point out that this conflicts with a python installation, wher
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 11, 2008, at 3:58 AM, Wichert Akkerman wrote:
- add another path (e.g. /usr/local/python/lib2.x/site-packages),
and remove the /usr/local/lib/python2.x/site-packages path after
the next release. Does provide an upgrade path, but doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 11, 2008, at 6:36 PM, Floris Bruynooghe wrote:
On Tue, Mar 11, 2008 at 09:45:21AM -0400, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 11, 2008, at 3:43 AM, Matthias Klose wrote:
Currently Debian's pytho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2008, at 6:23 AM, Emilio Pozuelo Monfort wrote:
Barry Warsaw wrote:
This is Debian policy (which is fine), but I don't think all distros
agree. I'm not a distro guy though. :) Mattias, didn't the Fedora
guys
say the
I know I'm coming in the middle of this, and I'm sure I don't understand all
the issues yet, but I'll chime in here anyway. :)
On Jan 19, 2010, at 10:39 AM, Josselin Mouette wrote:
>I’m also still wondering which exact problem this proposal is trying to
>fix. Currently the only thing it does seem
On Jan 29, 2010, at 11:42 PM, Ben Finney wrote:
> Umang writes:
>
>> What I am talking about is the upstream tarball that, when extracted
>> into a directory, can run without being installed using distutils.
>
> If the package is designed to be installed by distutils, it seems obtuse
> to expec
On Jan 30, 2010, at 4:56 PM, Josselin Mouette wrote:
> Maybe you don’t understand it is a plague, because you are not trying to
> package the things you write with __file__ for a distribution. The
> location of module files on the system should be a hidden implementation
> detail. Because of __fil
On Jan 31, 2010, at 01:09 AM, Josselin Mouette wrote:
>pkg_resources allows to do things correctly, but I find it too complex;
>it’s no wonder why people still hack stuff around __file__: it’s much
>simpler.
I think it's not so much that pkg_resources is complex, but that it has a lot
of extra AP
On Jan 31, 2010, at 08:53 PM, Umang wrote:
>But I'll never find my data files in sys.prefix +
>path_i_asked_distutils_to_install_to. So what according to you, is the
>right way to go about distributing? This situation is definitely not ideal.
The Pythonic way (IMO) is to use pkg_resources:
htt
On Feb 14, 2010, at 09:18 AM, Paul Wise wrote:
>Unless they can be convinced to undo that, python-json is clearly at a
Very unlikely that will happen.
-Barry
signature.asc
Description: PGP signature
On Mar 15, 2010, at 08:47 PM, Jonathan Wiltshire wrote:
>It occurs to me that there's very little guarantee of a stable API in
>Python modules - less so in C modules, because upstream tends to be more
>aware that this is a library, but in pure Python modules.
There is nothing other than conventio
On Mar 29, 2010, at 08:39 AM, C.J. Adams-Collier wrote:
>I'm pretty new to packaging python. Apologies in advance if I'm making
>bad assumptions. I recently packaged IronPython. It can optionally use
>the libraries from the standard python library. It doesn't seem that
>these libs are distribu
On Apr 14, 2010, at 04:14 PM, Jakub Wilk wrote:
>python-central seems to have some (at least rudimentary) support for
>3.X.
>
>I was told that python-support does not support 3.X (see bug #573560).
I am hoping that none will be necessary. PEP 3147 is very close to acceptance
and merging into t
On Apr 14, 2010, at 07:01 PM, Josselin Mouette wrote:
>Le mercredi 14 avril 2010 à 10:29 -0400, Barry Warsaw a écrit :
>> >I was told that python-support does not support 3.X (see bug #573560).
>>
>> I am hoping that none will be necessary. PEP 3147 is very close
On Apr 14, 2010, at 09:26 PM, Piotr Ożarowski wrote:
>[4] almost ready in pycompile, still waiting for
>http://www.python.org/dev/peps/pep-0382/ (and 3147), though
PEPs 382 and 384 are next on my list.
-Barry
signature.asc
Description: PGP signature
Apologies for the cross-post, but I want to make sure that everyone who cares
about Python on both Debian and Ubuntu gets a chance to weigh in.
On Friday, Guido approved and I landed the implementation of PEP 3147 on the
py3k trunk (what will be Python 3.2). This allows multiple versions of Pytho
On Apr 20, 2010, at 06:50 AM, Omer Zak wrote:
>My take of the situation:
>Yes, please backport PEP 3147 to at least Python 2.7.
>The rationale: we'll need to support both Python 2.x and Python 3.x for
>several years, and it will be nice if the same library package can be
>made to support both 2.x
On Apr 20, 2010, at 10:14 AM, Piotr Ożarowski wrote:
>[Omer Zak, 2010-04-20]
>> My take of the situation:
>> Yes, please backport PEP 3147 to at least Python 2.7.
>> The rationale: we'll need to support both Python 2.x and Python 3.x for
>> several years, and it will be nice if the same library pa
On Apr 21, 2010, at 02:43 PM, Piotr Ożarowski wrote:
>> Moreover AFAICT 2.7 is the most compatible-with-the-previous-version
>> Python release in the last 16 years
>
>did you hear about relative imports in 2.7? (enormous transition for us)
Are you sure about this? Despite what PEP 328 says, I'm
On Apr 21, 2010, at 08:33 PM, Piotr Ożarowski wrote:
>[Piotr Ożarowski, 2010-04-21]
>> should be easy to check (by creating 2 simple .py files and running
>> them using python2.7 from experimental). I'll check it later tonight.
>
>It's not enabled (fails only if I import absolute_import from
>__fu
On Apr 20, 2010, at 04:57 PM, Scott Kitterman wrote:
>I think it is difficult to know for sure what the future will hold. If the
>backport is not technically complex, I think a backport with the default to
>off would be a nice tool in the box is things go differently than we plan.
>Other than the
On Apr 21, 2010, at 12:01 AM, Piotr Ożarowski wrote:
>2to3 is not reliable, at least not for now.
I agree that there's no way we can just enable it by default. Too many
upstream packages need modifications to work in Python 3. However, for those
that are Python 3-ready, it's a useful tool. The
On Apr 22, 2010, at 01:47 PM, Scott Kitterman wrote:
>Based on my experience with the Python 2.5 and 2.6 transitions, I'd really
>prefer to have Ubuntu follow Debian rather than lead.
Ideally, yes I'd like the same thing, but I'll need help because I'm so new to
Debian.
So if it makes sense for
On Apr 21, 2010, at 12:03 AM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2010-04-20]
>> If 10.10 includes
>> only Python 2.7, then sure, we'll only back port to that version.
>
>why do you want to backport it to 2.X for a single python2.x package?
It would only make s
on Debian and Ubuntu.
>On Thu, Apr 22, 2010 at 01:52:11PM -0400, Barry Warsaw wrote:
>> How much of the transition testing is automated? It would be very
>> interesting
>> for example, to have a test framework that could run any combination of
>> Python
>>
On Apr 27, 2010, at 10:01 AM, Nicolas Chauvat wrote:
>[discussion started at
>http://lists.debian.org/debian-python/2010/04/msg00046
>should we continue or trim some of the cc'ed lists ?]
Is there a better place to discuss Python packaging issues that are of
interest to both Debian and Ubuntu? A
On Apr 27, 2010, at 06:32 PM, Toni Mueller wrote:
>I'm not sure about how much the changes in the infrastructure would be
>an obstacle, or prevent this from happening (didn't check yet), and I
>don'tknow how the group thinks about the political and/or personal
>issues involved, either. What I do s
On May 04, 2010, at 04:20 PM, Richard Darst wrote:
>I was looking through the talks submitted to DebConf, and noticed
>there weren't very many Python related talks. Given the amount there
>is to discuss related to Python in Debian, it would be great to see
>some more submissions.
I wish I could
On May 05, 2010, at 11:54 AM, Piotr Ożarowski wrote:
>What do you think about backporting it to Python 3.1 in Squeeze?
>
>I think it's worth to backport it to python3.1 even if it will be the
>only 3.X version supported in Squeeze as this should ease the transition
>to python3.2 in Squeeze+1 and g
On May 08, 2010, at 10:55 AM, Piotr Ożarowski wrote:
>The only reason I got from Ubuntu for doing transitions outside Debian
>and allowing Debian to do it later (and forcing us to fix after them)
>is... "because you are slow". All technical reasons (like relative
>imports in 2.6) were easy to prov
Now that the Ubuntu Developer Summit is over, I'll be able to catch up on this
mailing list. However I wanted to take a moment to summarize the session we
had on Python versions for Maverick Meerkat (Ubuntu 10.10).
First, let me thank the DPL Stefano Zacchiroli for coming to UDS-M and
representin
On May 18, 2010, at 10:52 AM, Kumar Appaiah wrote:
>On Tue, May 18, 2010 at 11:38:23AM -0400, Barry Warsaw wrote:
>> First, let me thank the DPL Stefano Zacchiroli for coming to UDS-M and
>> representing the Debian community. It was really great meeting and having a
>> ch
On May 18, 2010, at 02:30 PM, Scott Kitterman wrote:
>As is usual for discussions involving more than one person, we didn't all
>leave the room with quite the same understanding. I think 2.7 as default is a
>stretch goal at most. We want 2.7 as a supported version, but I didn't sense
>a lot of app
I just hope you'll be patient with me asking lots of dumb
questions. You can always tell me to RTFWP (RTF Web Page :).
>On Tue, May 18, 2010 at 23:50, Barry Warsaw wrote:
>> On May 18, 2010, at 02:30 PM, Scott Kitterman wrote:
>>>We did make the assumption that by the time
On May 19, 2010, at 11:00 AM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2010-05-18]
>> We can also recognize that Ubuntu and Debian may ultimately
>> make different decisions, but they should be one of timing rather than
>> substance. What I mean by that is that we can use
On May 19, 2010, at 01:05 PM, Piotr Ożarowski wrote:
>[Piotr Ożarowski, 2010-05-19]
>> we have experimental for aggressive changes...
>
>unless you wanted to use Debian experimental, debian-python mailing list
>and our help since the beginning and later sync it in Ubuntu (if you
>decide it's ready
On May 26, 2010, at 05:43 PM, Scott Kitterman wrote:
>I think it makes sense for them to be kept separate at runtime.
>
>This would mean separate python-foo and python3-foo binaries where both are
>supported from the same source.
>
>It would mean that binaries should not depend on both Python 2 a
On May 23, 2010, at 03:58 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2010-05-22]
>> So, how can we make sure that doesn't happen? IOW, how can I begin to
>> experiment with a Python 2.7 transition in a way that will benefit Debian as
>> well?'
>
>Simply avo
On May 16, 2010, at 02:21 PM, Piotr Ożarowski wrote:
>What's missing to have full PEP3147 support?
>* PEP 384 implementation (will allow us to share (most?) .so files)
I have a concern about this.
While I understand the motivation, I'm not sure implementing PEP 384 will have
any practical help i
On May 10, 2010, at 01:23 PM, Piotr Ożarowski wrote:
>Why I think derivatives should not add new versions?
>* because it's mostly chasing numbers - I'm pretty sure there are not
> more than 10 packages that require Python >= 2.6 and are not easy to
> port to 2.5 in Ubuntu 10.04,
>* because when
On May 18, 2010, at 11:42 PM, anatoly techtonik wrote:
>On Mon, May 10, 2010 at 2:23 PM, Piotr Ożarowski wrote:
>>
>> Why I think derivatives should not add new versions?
>> * because it's mostly chasing numbers - I'm pretty sure there are not
>> more than 10 packages that require Python >= 2.6
I know I'm a broken record on this, and I (currently ;) have very little power
to do much about it other than *talk*, but...
On May 11, 2010, at 10:18 PM, Piotr Ożarowski wrote:
>Why am I mentioning Ubuntu at all? Because all decisions about Python in
>Debian are made there.
My own personal hope
On May 06, 2010, at 04:47 PM, Lino Mastrodomenico wrote:
>2010/5/5 Barry Warsaw :
>> users of Python 3.1 might be surprised by the difference from upstream
>
>It might be useful mentioning somewhere that the best way to detect if
>the Python implementation used supports PEP 3147
On May 28, 2010, at 01:33 PM, Piotr Ożarowski wrote:
>Jakub Wilk found the problem and prepared a list of packages affected:
>http://people.debian.org/~jwilk/tmp/string-exceptions.ddlist
>
>anyone volunteers to check them and report bugs?
>
>(string exceptions are not allowed in Python >= 2.6)
So
On May 28, 2010, at 04:35 PM, Jakub Wilk wrote:
>* Barry Warsaw , 2010-05-28, 10:21:
>>>Jakub Wilk found the problem and prepared a list of packages affected:
>>>http://people.debian.org/~jwilk/tmp/string-exceptions.ddlist
>>>
>>>anyone volunteers to che
On May 28, 2010, at 01:24 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2010-05-28]
>> What I mean is, let's say we have to change something in a helper tool. We
>> want that change to happen at least also in Debian, if not first in Debian,
>> but because of our diffe
On May 28, 2010, at 07:21 PM, Jakub Wilk wrote:
>Let's try what says grep on the Lucid's vesrion:
>
>$ grep -Er "raise\s+[\"']" --include='*.py' bzr-2.1.1/
>bzr-2.1.1/bzrlib/bundle/bundle_data.py:raise 'Value %r has
>no colon' % info_item
>bzr-2.1.1/bzrlib/tests/test_hooks.py:
I realize that I've never formally requested addition to DPMT and PAPT. Since
I maintain both upstream Python applications and modules, and since I'm on the
core Python development team, I would like to request admission to both Debian
teams. I'll start off by maintaining the various packages tha
On May 29, 2010, at 11:18 PM, Bernd Zeimetz wrote:
>On 05/28/2010 09:10 PM, Barry Warsaw wrote:
>> I realize that I've never formally requested addition to DPMT and PAPT.
>> Since
>> I maintain both upstream Python applications and modules, and since I'm on
&g
On Jun 05, 2010, at 10:43 PM, Scott Kitterman wrote:
I filed a bug on bzr and it was fixed, though I don't know if it's released
yet or not. It was a corner case anyway so probably not a show stopper.
-Barry
signature.asc
Description: PGP signature
On Jun 18, 2010, at 03:45 PM, Piotr Ożarowski wrote:
>[Luca Falavigna, 2010-06-18]
>> Il 18/06/2010 14.37, Scott Kitterman ha scritto:
>> > XS-Python-Version: >= 2.x
>> > XS-Python3-Version: >= 3.x
>
>+1 (but with XB-Python-Version, i.e. no XB-Python3-Version)
Agreed. This aligns with the decisi
On Jun 18, 2010, at 04:30 PM, Julian Andres Klode wrote:
>Another reason against this would be that it will look stupid once there
>is no Python 2 anymore.
If it's one thing I've learned in all my years is that it's virtually
impossible not to look stupid 10 or 15 years later . I mean, have you
On Jun 20, 2010, at 04:28 PM, Scott Kitterman wrote:
>> I'm going to declare rough consensus around this approach and I'll have a
>> Python policy patch for review shortly.
I haven't had time to read this through yet, but I recently posted some
information related to Python on Debian and Ubuntu a
On Jun 21, 2010, at 06:30 PM, Scott Kitterman wrote:
>I think most people install Python modules and extensions as dependencies of
>applications they care to use. For Python developers that actually care
>about such things, I think it's better that the just install both manually.
I agree about t
On Jun 22, 2010, at 12:13 AM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2010-06-21]
>> I haven't had time to read this through yet, but I recently posted some
>> information related to Python on Debian and Ubuntu and requested off-list
>> feedback. One of the more inte
For those of you not closely following python-dev, I've made a proposal for
versioned .so file naming for Python 3.2. It would allow us to place
extension module .so files for different Python versions (or really, Python
builds, e.g. 3.2/3.3, debug, UCS2/4, etc) in the same directory without namin
On Jun 24, 2010, at 11:58 PM, Jakub Wilk wrote:
>What's the point in making distutils produce versioned .so? Such a change is
>going to break lots of packages for exactly zero benefit:
Why so?
>helper tools will need to do unversioned->versioned renames anyway, in order
>to handle non-distutils
On Jun 30, 2010, at 04:58 PM, Scott Kitterman wrote:
>On Wednesday, June 30, 2010 04:51:38 pm Piotr Ożarowski wrote:
>> [Scott Kitterman, 2010-06-30]
>>
>> > For Python3:
>> >
>> > 1. A new field called X-Python3-Version: It does not support lists of
>> > versions (e.g. (3.0, 3.1)). Acceptabl
On Jun 30, 2010, at 06:02 PM, Scott Kitterman wrote:
>I don't want to break a lot of packages. Both implicit and explicit
>all are widely used in Python packages. I think we have more freedom
>to do the "right" thing for Python 3.
That's what I expected (i.e. "cleans up a wart"). +1
Thanks,
-Ba
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
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
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 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 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 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 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
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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
: 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 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.
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 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
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
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
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
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
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 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
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 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 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 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 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 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 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 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 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
1 - 100 of 859 matches
Mail list logo
