On Thursday, April 16, 2015 06:45:08 PM Stefano Rivera wrote:
Hi Scott (2015.04.15_18:30:23_+0200)
If we are sharing dist-packages, then pypy can probably use the same
binary when the content would be the same. Only in cases where the
content is different would you duplicate a separate
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
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 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 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
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
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 April 14, 2015 6:01:56 PM EDT, Paul Tagliamonte paul...@debian.org wrote:
=== BITS FROM THE DEBIAN PYCON HANGOUT ===
Agenda:
- Discuss how we might support multiple interpreters with Python 3
packages, for cpython + pypy C extensions.
- Set up a plan
=== BITS FROM THE DEBIAN PYCON HANGOUT ===
Agenda:
- Discuss how we might support multiple interpreters with Python 3
packages, for cpython + pypy C extensions.
- Set up a plan for the svn = git migration
- Python 2 deprecation
- /usr/bin/python
Paul Tagliamonte paul...@debian.org writes:
=== BITS FROM THE DEBIAN PYCON HANGOUT ===
Thanks for posting this so promptly, Paul!
--
\ “Not using Microsoft products is like being a non-smoker 40 or |
`\ 50 years ago: You can choose not to smoke, yourself, but it's
Paul Tagliamonte paul...@debian.org writes:
SVN = GIT
--
We should just do it!
+1
[…]
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.
I
22 matches
Mail list logo
