On Apr 15, 2015, at 09:05 AM, Ben Finney wrote:
I use the “merge when building the source package” workflow, where the
upstream source is a tarball outside the working tree, not part of the
Debian packaging VCS at all.
See ‘git-buildpackage(1)’, the ‘--git-overlay’ option.
Is that still a
On Apr 15, 2015, at 09:34 AM, Barry Warsaw wrote:
Is that still a wholly compatible workflow with what is being proposed?
I think so, but I haven't played with --git-overlay.
Oops, I misread. To be clear, I think the patch regimes are not compatible
with --git-overlay, but I could be wrong.
Hi Paul (2015.04.15_16:53:04_+0200)
See ‘git-buildpackage(1)’, the ‘--git-overlay’ option.
Is that still a wholly compatible workflow with what is being proposed?
I have this workflow as well, and this would even work really well with
our current svn repos, but folks in the room at
On Wednesday, April 15, 2015 04:54:45 PM Stefano Rivera wrote:
Hi Scott (2015.04.15_02:17:18_+0200)
Consensus seems to be give it a shot and try to see what works.
There are no pypy apps, so this isn't an issue yet.
What is the it that's to be given a shot? I see two choices there?
On Wed, Apr 15, 2015 at 09:05:06AM +1000, Ben Finney wrote:
Paul Tagliamonte paul...@debian.org writes:
All present felt strongly that we should always use pristine upstream
tarballs as released by upstreams, with pristine-tar.
I'm glad of the former. I don't use ‘pristine-tar’, though.
Hi Scott (2015.04.15_02:17:18_+0200)
Consensus seems to be give it a shot and try to see what works.
There are no pypy apps, so this isn't an issue yet.
What is the it that's to be given a shot? I see two choices there?
Give python3 + pypy3 shared dist-packages a shot.
Did you discuss the
Hi Scott (2015.04.15_17:19:39_+0200)
Since these pypy extension packages are new and there are no applications, I
think it would make a lot of sense to limit this to PY3. It makes things
much
simpler technically. We should not recreate the symlink farm we used to have
for python.
I
Hi Scott (2015.04.15_02:17:18_+0200)
Upstream Python's direction for Python paths is in favor of explicitly
numbered
/usr/bin/python2 and /usr/bin/python3. In support of this, rough
consensus in
the room is that /usr/bin/python should likely be removed *entirely*
from
shebangs (though not
On April 15, 2015 11:17:52 AM EDT, Stefano Rivera stefa...@debian.org wrote:
Hi Scott (2015.04.15_02:17:18_+0200)
Upstream Python's direction for Python paths is in favor of
explicitly
numbered
/usr/bin/python2 and /usr/bin/python3. In support of this, rough
consensus in
the room is that
On April 15, 2015 11:24:30 AM EDT, Stefano Rivera stefa...@debian.org wrote:
Hi Scott (2015.04.15_17:19:39_+0200)
Since these pypy extension packages are new and there are no
applications, I
think it would make a lot of sense to limit this to PY3. It makes
things much
simpler technically.
On Apr 15, 2015, at 12:24 PM, Scott Kitterman wrote:
Maybe I'll mellow over time, but currently my thinking is that if there's an
upload to point /usr/bin/python at a python3, it will be immediately followed
by one where I remove myself from being maintainer. It's an idea that can
only cause
Heyya d-p,
I'd like to send an email to d-d-a asking that project to consider no
longer creating new Debian tools in Python 2.
I'd like this to have the endorsement of the team, so, does anyone object to
me asking people to not write new tools in Python 2 only (prefer alternative
deps or
On Wednesday, April 15, 2015 02:16:58 PM Barry Warsaw wrote:
On Apr 15, 2015, at 12:24 PM, Scott Kitterman wrote:
Maybe I'll mellow over time, but currently my thinking is that if there's
an upload to point /usr/bin/python at a python3, it will be immediately
followed by one where I remove
On Wednesday, April 15, 2015 04:27:51 PM Paul Tagliamonte wrote:
Heyya d-p,
I'd like to send an email to d-d-a asking that project to consider no
longer creating new Debian tools in Python 2.
I'd like this to have the endorsement of the team, so, does anyone object to
me asking people to
On Wed, Apr 15, 2015 at 3:27 PM, Paul Tagliamonte paul...@debian.org
wrote:
Heyya d-p,
I'd like to send an email to d-d-a asking that project to consider no
longer creating new Debian tools in Python 2.
I'd like this to have the endorsement of the team, so, does anyone object
to
me asking
Perfect, thanks, Ian! I'll get a ML for a Python 3 porting SWAT team
together once we make sure no one has a sane technical reason to avoid
this so soon (I don't think there's any)
Thanks, Ian! Excited to work with you!
Paul
On Wed, Apr 15, 2015 at 4:35 PM, Ian Cordasco
I was saying the same thing in my head, but as i thought about it, if the
cpython maint team (hi doko) wants it, I don't see why not :)
I phrased it in such a way in my mail that I feel comfortable sending my
draft and then working out details without setting ftpteam policy first
On Apr 15, 2015
On Wednesday, April 15, 2015 11:00:53 PM Stefano Rivera wrote:
Hi Scott (2015.04.15_22:42:26_+0200)
P.S. It would be nice if there would be a PEP that says to never ever do
this. I know it would make Arch have a sad, but they'll get over it.
I think everyone wants to make Arch sad. In
On Wednesday, April 15, 2015 11:07:13 PM Matthias Klose wrote:
On 04/15/2015 10:27 PM, Paul Tagliamonte wrote:
Heyya d-p,
I'd like to send an email to d-d-a asking that project to consider no
longer creating new Debian tools in Python 2.
I'd like this to have the endorsement of the
On Apr 15, 2015, at 04:42 PM, Scott Kitterman wrote:
Then I don't understand why the whole s/python/python2// plan in the shebangs
helps anything. As long as both exist, it's a no-op.
Partly this is to begin to educate users to stop using /usr/bin/python, which
has unclear semantics across the
I'll add a note about that, and talk with the ftpteam to see if we can
implement that policy in NEW.
Mails on the thread seem positive so far, I'll post this to d-d-a when I
get home from YUL to DC tonight.
On Apr 15, 2015 5:07 PM, Matthias Klose d...@debian.org wrote:
On 04/15/2015 10:27 PM,
On Apr 15, 2015, at 04:27 PM, Paul Tagliamonte wrote:
I'd like this to have the endorsement of the team
Looks like you don't need my +1 but I'll give it anyway. :)
I'll make note of a team which should exist to help with such porting,
(I'm up to help with this)
I'm up for helping too, of
It's worth mentioning that in virtualenvs and conda envs, where there can
only be one version of Python installed, 'python' refers to that whether it
is Python 3 or 2. So it's already not a safe assumption that 'python'
always means Python 2, even if you discount Arch.
On 15 April 2015 at 21:04,
The odds of system management scripts I wrote a decade ago and haven't touched
since living in a virtualenv is approximately zero. The issue with switching
where /usr/bin/python points to python3 is to avoid problems on systems. I
don't think virtualenv is relevant. In any case, if you're
Paul Tagliamonte paul...@debian.org writes:
I'll make note of a team which should exist to help with [porting
packages to Python 3 compatibility], (I'm up to help with this) that
was one of the items that came out of the PyCon chit-chat.
I have recent experience making code bases Python 2 and
I am happy to help porting things. I did it for a number of non trivial
packages and happy to do more. It's very soothing experience and better
than knitting sudoku.
On 15 Apr 2015 2:29 pm, Paul Tagliamonte paul...@debian.org wrote:
Heyya d-p,
I'd like to send an email to d-d-a asking that
On 2015-04-15 16:27, Paul Tagliamonte wrote:
I'd like to send an email to d-d-a asking that project to consider no
longer creating new Debian tools in Python 2.
Makes sense.
I try to use Py3 whenever possible. Sometimes some libs are still
missing, mainly when upstream is not very active. My
Hi Scott (2015.04.15_22:42:26_+0200)
P.S. It would be nice if there would be a PEP that says to never ever do
this. I know it would make Arch have a sad, but they'll get over it.
I think everyone wants to make Arch sad. In retaliation for them making
us sad. Apparently there were many
On 04/15/2015 10:27 PM, Paul Tagliamonte wrote:
Heyya d-p,
I'd like to send an email to d-d-a asking that project to consider no
longer creating new Debian tools in Python 2.
I'd like this to have the endorsement of the team, so, does anyone object to
me asking people to not write new
29 matches
Mail list logo
