On 3 September 2016 at 14:32, Nick Coghlan wrote:
> On 2 September 2016 at 02:29, Avram Lubkin wrote:
>> On Thu, Sep 1, 2016 at 10:22 AM, Petr Viktorin wrote:
>>>
>>>
>>> Whatever we do, I'd like it to be coordinated across multiple
>>> distrubutions, and blesed by a PEP like [PEP 394]. We don't
On Sat, Sep 3, 2016 at 2:32 PM, Nick Coghlan wrote:
>
> * Tier 0: "the default Python" is determined at the distribution
> level. For the majority of current distributions, that means Python 2,
> but on a select few it means Python 3.
>
> * Tier 1: "the default Python" is configurable on a per-sy
On 2 September 2016 at 02:29, Avram Lubkin wrote:
> On Thu, Sep 1, 2016 at 10:22 AM, Petr Viktorin wrote:
>>
>>
>> Whatever we do, I'd like it to be coordinated across multiple
>> distrubutions, and blesed by a PEP like [PEP 394]. We don't want a solution
>> specific to Fedora.
We do need to fig
On 1 September 2016 at 22:04, Avram Lubkin wrote:
>
> On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan wrote:
>>
>>
>> The ideal point we'd like to get to is one where all distro provided
>> scripts actually have the appropriate major version in their shebang
>> lines, and the unqualifed "python" is
On Thu, Sep 1, 2016 at 10:22 AM, Petr Viktorin wrote:
>
> Whatever we do, I'd like it to be coordinated across multiple
> distrubutions, and blesed by a PEP like [PEP 394]. We don't want a solution
> specific to Fedora.
>
Completely agree. Based on the suggestions offered in PEP 394, we would
ne
On 09/01/2016 01:44 PM, Nick Coghlan wrote:
For /usr/bin/python, we had an upstream discussion about that at the
2015 language summit: https://lwn.net/Articles/640296/
Whatever we do, I'd like it to be coordinated across multiple
distrubutions, and blesed by a PEP like [PEP 394]. We don't want
On Thu, Sep 1, 2016 at 8:40 AM, Neal Gompa wrote:
> Sure, but those scripts may not actually work because modules that are
> supposed to be there, aren't. For example, if you depend on a
> non-standard lib module, then that means it needs to be installed for
> each python version supported. How d
On Thu, Sep 1, 2016 at 8:33 AM, Avram Lubkin wrote:
> On Thu, Sep 1, 2016 at 8:14 AM, Neal Gompa wrote:
>>
>> Alternatives doesn't work in this case because Python 2.x and Python
>> 3.x versions don't share resources, even with minor versions of the
>> same series. Enabling alternatives for it is
On Thu, Sep 1, 2016 at 8:14 AM, Neal Gompa wrote:
> Alternatives doesn't work in this case because Python 2.x and Python
> 3.x versions don't share resources, even with minor versions of the
> same series. Enabling alternatives for it is a recipe for disaster.
>
Could you elaborate? The use case
On Thu, Sep 1, 2016 at 8:04 AM, Avram Lubkin wrote:
>
> On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan wrote:
>>
>>
>> The ideal point we'd like to get to is one where all distro provided
>> scripts actually have the appropriate major version in their shebang
>> lines, and the unqualifed "python" i
On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan wrote:
>
> The ideal point we'd like to get to is one where all distro provided
> scripts actually have the appropriate major version in their shebang
> lines, and the unqualifed "python" is something along the lines of a
> user-configurable launcher,
On 31 August 2016 at 23:54, Charalampos Stratakis wrote:
> Hello Python-SIG,
>
> Currently I am working on some ideas regarding the python package.
>
> Nothing is too concrete yet, however the technical side should be fairly
> simple.
>
> The first thing is renaming py
Hello Python-SIG,
Currently I am working on some ideas regarding the python package.
Nothing is too concrete yet, however the technical side should be fairly simple.
The first thing is renaming python to python2.
Currently the python packaging guidelines, suggest that we use the
13 matches
Mail list logo
