On 30 May 2013 04:40, "Barry Warsaw" wrote:
>
> On May 29, 2013, at 01:01 PM, Nick Coghlan wrote:
>
> >PEP 432 is also related, as it includes the "pysystem" proposal [1]
> >(an alternate Python CLI that will default to -Es behaviour, but is
> >otherwise similar to the standard "python" interprete
On May 29, 2013, at 01:01 PM, Nick Coghlan wrote:
>PEP 432 is also related, as it includes the "pysystem" proposal [1]
>(an alternate Python CLI that will default to -Es behaviour, but is
>otherwise similar to the standard "python" interpreter).
I *knew* this was being specified somewhere, but I
On May 28, 2013, at 12:23 PM, Toshio Kuratomi wrote:
>> Note that the Gentoo example also takes into account versions that might act
>> differently based on the interpreter's implementation. So a -python3 suffix
>> may not be enough. Maybe now we're getting into PEP 425 compatibility tag
>> terr
On May 28, 2013, at 08:02 PM, Antoine Pitrou wrote:
>On Tue, 28 May 2013 13:27:18 -0400
>Barry Warsaw wrote:
>> On May 25, 2013, at 09:53 AM, Antoine Pitrou wrote:
>>
>> >How about always running the version specific targets, e.g.
>> >nosetests-2.7?
>>
>> We have nosetests-2.7 and nosetests3 in
On Wed, May 29, 2013 at 5:23 AM, Toshio Kuratomi wrote:
> On Tue, May 28, 2013 at 01:22:01PM -0400, Barry Warsaw wrote:
>> On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:
>>
>> >- If upstream doesn't deal with it, then we use a "python3-" prefix. This
>> >matches with our package naming
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/28/2013 05:52 PM, R. David Murray wrote:
> On Tue, 28 May 2013 12:17:49 -0400, Tres Seaver
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 05/28/2013 11:41 AM, R. David Murray wrote:
>>> I have the same complaint about setupt
On Tue, 28 May 2013 12:17:49 -0400, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/28/2013 11:41 AM, R. David Murray wrote:
> > I have the same complaint about setuptools entry-point scripts, where
> > I still haven't figured out how to go from what is in the file
On Tue, May 28, 2013 at 01:22:01PM -0400, Barry Warsaw wrote:
> On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:
>
> >- If upstream doesn't deal with it, then we use a "python3-" prefix. This
> >matches with our package naming so it seemed to make sense. (But
> >Barry's point about l
On Tue, May 28, 2013 at 2:04 PM, Barry Warsaw wrote:
> On May 28, 2013, at 01:57 PM, Daniel Holth wrote:
>
>>Wheel has no mechanism for renaming scripts (or any file) based on the
>>Python version used to install. Instead you would have to build
>>python-version-specific packages for each desired
On May 28, 2013, at 01:57 PM, Daniel Holth wrote:
>Wheel has no mechanism for renaming scripts (or any file) based on the
>Python version used to install. Instead you would have to build
>python-version-specific packages for each desired script name.
Note that I'm not trying to borrow any impleme
On Tue, 28 May 2013 13:27:18 -0400
Barry Warsaw wrote:
> On May 25, 2013, at 09:53 AM, Antoine Pitrou wrote:
>
> >How about always running the version specific targets, e.g.
> >nosetests-2.7?
>
> We have nosetests-2.7 and nosetests3 in /usr/bin, but we generally recommend
> folks not use these,
On Tue, May 28, 2013 at 1:30 PM, Barry Warsaw wrote:
> On May 25, 2013, at 03:12 AM, Chris McDonough wrote:
>
>>You probably already know this, but I'll mention it anyway. This
>>probably matters a lot for nose and pyflakes, but I'd say that for tox
>>it should not, it basically just scripts exec
On May 25, 2013, at 03:12 AM, Chris McDonough wrote:
>You probably already know this, but I'll mention it anyway. This
>probably matters a lot for nose and pyflakes, but I'd say that for tox
>it should not, it basically just scripts execution of shell commands.
>I'd think maybe in cases like tox
On May 25, 2013, at 09:53 AM, Antoine Pitrou wrote:
>How about always running the version specific targets, e.g.
>nosetests-2.7?
We have nosetests-2.7 and nosetests3 in /usr/bin, but we generally recommend
folks not use these, especially for things like (build time) package tests.
It's harder to
On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:
>Fedora is a bit of a mess... we try to work with upstream's intent when
>upstream has realized this problem exists and have a single standard when
>upstream does not. The full guidelines are here:
>
>http://fedoraproject.org/wiki/Packaging:Pyt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/28/2013 11:41 AM, R. David Murray wrote:
> I have the same complaint about setuptools entry-point scripts, where
> I still haven't figured out how to go from what is in the file to the
> code that actually gets called.
Hmm, just dump the 'entr
On May 25, 2013, at 06:17 AM, Chris McDonough wrote:
>I'm curious if folks have other concrete examples of global bindir
>executables other than nosetests and pydoc that need to be disambiguated
>by Python version. I'd hate to see it become standard practice to
>append "3" to scripts generated by
On May 25, 2013, at 05:57 PM, Nick Coghlan wrote:
>It seems to me the existing recommendation to use ``#!/usr/bin/env
>python`` instead of referencing a particular binary already covers the
>general case. The challenge for the distros is that we want a solution
>that *ignores* user level virtual e
On Tue, 28 May 2013 11:35:00 -0400, Barry Warsaw wrote:
> On May 24, 2013, at 04:23 PM, R. David Murray wrote:
>
> >Gentoo has a (fairly complex) driver script that is symlinked to all
> >of these bin scripts. The system then has the concept of the
> >"current python", which can be set to python
On May 24, 2013, at 04:23 PM, R. David Murray wrote:
>Gentoo has a (fairly complex) driver script that is symlinked to all
>of these bin scripts. The system then has the concept of the
>"current python", which can be set to python2 or python3. The default
>bin then calls the current default inte
On Sat, May 25, 2013 at 05:57:28PM +1000, Nick Coghlan wrote:
> On Sat, May 25, 2013 at 5:56 AM, Barry Warsaw wrote:
> > Have any other *nix distros addressed this, and if so, how do you solve it?
>
> I believe Fedora follows the lead set by our own makefile and just
> appends a "3" to the script
On Sat, May 25, 2013 at 8:17 PM, Chris McDonough wrote:
> On Sat, 2013-05-25 at 17:57 +1000, Nick Coghlan wrote:
>> I think the simplest thing to do is just append the "3" to the binary
>> name (as we do ourselves for pydoc) and then abide by the
>> recommendations in PEP 394 to reference the corr
On Sat, 2013-05-25 at 17:57 +1000, Nick Coghlan wrote:
> I think the simplest thing to do is just append the "3" to the binary
> name (as we do ourselves for pydoc) and then abide by the
> recommendations in PEP 394 to reference the correct system executable.
I'm curious if folks have other concre
On Sat, May 25, 2013 at 5:56 AM, Barry Warsaw wrote:
> Have any other *nix distros addressed this, and if so, how do you solve it?
I believe Fedora follows the lead set by our own makefile and just
appends a "3" to the script name when there is also a Python 2
equivalent (thus ``pydoc3`` and ``py
On Fri, 24 May 2013 15:56:29 -0400
Barry Warsaw wrote:
> Here's something that seems to come up from time to time in Debian.
>
> Take a Python application like tox, nose, or pyflakes. Their executables work
> with both Python 2 and 3, but require a #! line to choose which interpreter to
> invoke
On Fri, 2013-05-24 at 15:56 -0400, Barry Warsaw wrote:
> Here's something that seems to come up from time to time in Debian.
>
> Take a Python application like tox, nose, or pyflakes. Their executables work
> with both Python 2 and 3, but require a #! line to choose which interpreter to
> invoke.
On Fri, May 24, 2013 at 10:23 PM, R. David Murray wrote:
> Gentoo has a (fairly complex) driver script that is symlinked to all
> of these bin scripts. The system then has the concept of the
> "current python", which can be set to python2 or python3. The default
> bin then calls the current defa
On Fri, 24 May 2013 15:56:29 -0400, Barry Warsaw wrote:
> Have any other *nix distros addressed this, and if so, how do you solve it?
> It would be nice if we could have some cross-platform recommendations so
> things work the same wherever you go. To that end, if we can reach some
> consensus, I
Here's something that seems to come up from time to time in Debian.
Take a Python application like tox, nose, or pyflakes. Their executables work
with both Python 2 and 3, but require a #! line to choose which interpreter to
invoke.
When we add Python 3 support in Debian for such a script, all t
29 matches
Mail list logo