On Mon, May 25, 2015 at 12:47:36PM +, Jelmer Vernooij wrote:
> FWIW, Dulwich supports Python3 these days [1]. We haven't actually put out
> a release with Python3 support yet, but that should happen shortly -
> along with an upload to unstable.
>
> experimental already has a `python3-dulwich`
On Thu, Apr 23, 2015 at 02:52:33PM +0200, Enrico Zini wrote:
> On Mon, Apr 20, 2015 at 11:14:28AM -0400, Paul Tagliamonte wrote:
>
> > So, round one of all of this is getting the critical path *under* each
> > of our services ready, so that when we need to migrate, we don't need
> > to scramble.
>
Hi,
I haven't been following this thread too closely, and I'm not familiar with
debian packaging related stuff. But I can help write code :)
>From what I see, we need people to help port python-git?
>From a search on debian packages, this is the package we're talking about:
https://packages.debia
On Apr 23, 2015, at 04:18 PM, Enrico Zini wrote:
>Since tox uses pip, which installs software to be run as my own user
>skipping the usual Debian trust chain, does it give any guarantee that I
>won't be running untrusted, unverified code as my user in my machine?
In the tox.ini, you should be abl
On Apr 23, 2015, at 08:05 AM, Nikolaus Rath wrote:
>Are you by any chance also familiar with pytest and could same a few
>word about pros/cons?
Of course this is all personal opinion, so take with a grain of salt. I know
a lot of people really like pytest but I don't use it. I don't like the us
On Thu, Apr 23, 2015 at 10:55:26AM -0400, Paul Tagliamonte wrote:
> Yep! So, my plan that I outlined on d-d-a was to basically attack that --
> the depends chains -- first. Since we are doing this before strictly
> needed (that is, nearly two cycles out), we can ensure everything is
> working and
On Apr 23 2015, Barry Warsaw wrote:
> There *are* however proven, stable tools that improve the Python coding and
> maintenance experience and for me, tox is one of those. There are others,
> such as nose2, that I won't even start a new project without adopting from the
> first commit.
Are you b
On Thu, Apr 23, 2015 at 09:17:38AM -0400, Scott Kitterman wrote:
> Where we started this was with a goal to make sure that 100% of needed
> depends
> will be available in Stretch, so that by the time Buster is released,
> services
> can be migrated. It'd be nice to migrate other things soone
On Thu, Apr 23, 2015 at 02:52:33PM +0200, Enrico Zini wrote:
> On Mon, Apr 20, 2015 at 11:14:28AM -0400, Paul Tagliamonte wrote:
>
> > So, round one of all of this is getting the critical path *under* each
> > of our services ready, so that when we need to migrate, we don't need
> > to scramble.
>
On Thu, Apr 23, 2015 at 09:36:50AM -0400, Barry Warsaw wrote:
> There *are* however proven, stable tools that improve the Python coding and
> maintenance experience and for me, tox is one of those. There are others,
> such as nose2, that I won't even start a new project without adopting from the
On Apr 23, 2015, at 03:15 PM, Enrico Zini wrote:
>[1] also, given the volatility of a lot of new tools in the python ecosystem,
>I have adopted the safety practice of making sure that a tool has been
>/widely/ adopted for at least a year or two before even bothering to look at
>it. I like that pra
On Apr 23, 2015, at 03:19 PM, Enrico Zini wrote:
> * I work on the code.
> * I run the py2 test suite.
> * I deploy.
> * /Someone else/ runs the py3 test suite and if needed sends patches.
I suggest using tox to ensure the tests run in all supported Python versions.
Actually, I suggest tox even i
On Mon, Apr 20, 2015 at 09:58:31PM +0200, Karsten Hilbert wrote:
> > Also, if I implement new features I am not necessarily going to test
> > them on python3 unless it somehow happens automatically. Running the
> > test suite twice is not much of an option, though, because it already
> > takes a l
On Thursday, April 23, 2015 02:52:33 PM Enrico Zini wrote:
> On Mon, Apr 20, 2015 at 11:14:28AM -0400, Paul Tagliamonte wrote:
> > So, round one of all of this is getting the critical path *under* each
> > of our services ready, so that when we need to migrate, we don't need
> > to scramble.
>
> T
On Mon, Apr 20, 2015 at 01:33:37PM -0400, Barry Warsaw wrote:
> Personally, I think the use of dict.iteritems is way overused. The
> performance hit is theoretical unless you've actually measured it, and even
> then I think it probably doesn't help much unless you've got huge dicts.
I tend not t
On Mon, Apr 20, 2015 at 11:14:28AM -0400, Paul Tagliamonte wrote:
> So, round one of all of this is getting the critical path *under* each
> of our services ready, so that when we need to migrate, we don't need
> to scramble.
There is another constraint that I forgot: the production environment i
On Mon, Apr 20, 2015 at 08:39:35AM -0400, Scott Kitterman wrote:
> I think the porting team would do most of the work, we'd just need you to
> review and integrate changes as they come along.
That works for me.
Enrico
--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini
--
To UNSUBSCRIBE, em
Barry Warsaw writes:
> Personally, I think the use of dict.iteritems is way overused.
It (as the trio of ‘dict.iterkeys’, ‘dict.itervalues’, ‘dict.iteritems’)
was heavily recommended from the time when the standard recommendation
was to use ‘2to3’. That tool could then tell whether the programme
> Also, if I implement new features I am not necessarily going to test
> them on python3 unless it somehow happens automatically. Running the
> test suite twice is not much of an option, though, because it already
> takes a lot of time to run, and doubling the time it takes just means
> that code i
On Apr 20, 2015, at 06:35 PM, Enrico Zini wrote:
>For the sites themselves, it depends. I use dict.iteritems a lot, and I
>do not intend to see my code migrated to use six.iteritems because it
>makes code hard to read, and it then requires a furter migration to make
>it readable again once there i
On Mon, Apr 20, 2015 at 11:14:28AM -0400, Paul Tagliamonte wrote:
> So, round one of all of this is getting the critical path *under* each
> of our services ready, so that when we need to migrate, we don't need
> to scramble.
>
> As a compromise to keep us both happy - if we were to focus on maki
On Mon, Apr 20, 2015 at 12:04:14PM +0200, Enrico Zini wrote:
> Hi. I welcome, in principle, migrations to python3. I like python3.4 more
> than python2, both the language and the stdlib it comes with.
:+1:
> This is a census of the services I'm maintaining, more comments will
> come after the cen
On Monday, April 20, 2015 12:04:14 PM Enrico Zini wrote:
> HOWEVER. I am the only person currently looking after all that code, and
> my development time on it is mostly spent fixing bugs and implementing
> the features that make it useful. See for example [1] and [2] for the
> kind of things that
On Thu, Apr 16, 2015 at 09:50:02AM -0400, Paul Tagliamonte wrote:
> - If *you* maintain or work on a Python 2 project that's used in Debian
> Development (buildd, release tools, QA tools, ftpteam tools), please
> email me a link to the project. An accurate census will help hugely.
On Apr 17, 2015, at 12:45 AM, Thomas Goirand wrote:
>I'd be happy to share some more links of useful stuff about porting to Python
>3 (I have some more on my "other laptop" (tm)). Is there already a page with
>some links on the subject in the Debian wiki?
Not in the Debian wiki (though it started
On 16/04/15 14:50, Paul Tagliamonte wrote:
Aloha, Developers!
Many of our projects in Debian are written in Python -- yay, Python!
However, a large chunk are implemented in Python 2 -- Booo, Python 2!
Background
==
Python 2 is scheduled to be EOL'd upstream officially and for good i
On 04/16/2015 03:50 PM, Paul Tagliamonte wrote:
If you're interested in this effort, please email me. This is a really good new
contributor task, so if anyone's asked you how they could get involved with
Debian, you should send them to us!
/me raises hand
I'm interested! :)
Generally speaking
On Apr 16, 2015, at 04:33 PM, Cyril Brulebois wrote:
>(Last time EOL approached, it was pushed back by 5 years, so…)
PEP 373 says that 2.7 will have bug fix releases until 2020. I suspect it
will continue to have security releases for some time after that, as long as
there's sufficient motivatio
Paul Tagliamonte (2015-04-16):
> Background
> ==
>
> Python 2 is scheduled to be EOL'd upstream officially and for good in 2020.
> We're in 2015 now (wow, that went quickly), and keeping our release cadence up
> (3 years a pop) puts Stretch up in 2018, and Buster in 2021.
Wheezy was firs
29 matches
Mail list logo
