On 3 September 2016 at 07:47, wrote:
> Nick might have something better to say about this, but I don’t think
> catching enterprise-y linux distros like RHEL out of the blue is a good way
> to go, so even if we decide right now to drop 2.6 support, it shouldn’t
> actually ship with breaking cha
On 2 September 2016 at 19:28, Paul Moore wrote:
> On 2 September 2016 at 09:58, Sylvain Corlay wrote:
>> My point here was that I don't think that the proposed feature has much to
>> do with the concerns that were raised about distutils in general, unless it
>> is decided that incremental improve
On 2 September 2016 at 13:30, Antony Lee wrote:
>> Similarly, it wouldn't astonish me if we eventually see an emergent
>> practice of people writing pyproject.toml.in files for complex
>> projects, in order to move some particular forms of complexity away
>> from build time and towards development
Therein lies my suggestion. Pick a date, announce, give 3 months, then stop
testing on 2.6
> -Original Message-
> From: Donald Stufft [mailto:don...@stufft.io]
> Sent: Friday, September 2, 2016 6:18 PM
> To: tritium-l...@sdamon.com
> Cc: distutils sig
> Subject: Re: [Distutils] When can
> On Sep 2, 2016, at 5:47 PM, tritium-l...@sdamon.com wrote:
>
> Nick might have something better to say about this, but I don’t think
> catching enterprise-y linux distros like RHEL out of the blue is a good way
> to go, so even if we decide right now to drop 2.6 support, it shouldn’t
> actua
Nick might have something better to say about this, but I don’t think catching
enterprise-y linux distros like RHEL out of the blue is a good way to go, so
even if we decide right now to drop 2.6 support, it shouldn’t actually ship
with breaking changes for like... 3 months? Maybe a little more
Kill it with fire!
On Sep 2, 2016 2:06 PM, "Donald Stufft" wrote:
> The packaging tools generally support 2.6+ and 3.(2|3)+ and that's sort of
> been
> where they've been at for a while now. I would like to think about what we
> need
> to be to start considering Python 2.6 as "too old" to suppor
The packaging tools generally support 2.6+ and 3.(2|3)+ and that's sort of been
where they've been at for a while now. I would like to think about what we need
to be to start considering Python 2.6 as "too old" to support. In pip we
generally follow a usage based deprecation/removal of supported Py
Thanks!
> On Sep 1, 2016, at 7:19 AM, Nick Coghlan wrote:
>
> Having reviewed the comments on the PEP 527 thread and the latest
> draft of the PEP, I'm now accepting the PEP. This means that:
>
> * supported sdist types will be reduced to .tar.gz and .zip
> * projects will need to choose one or
On 2 September 2016 at 09:58, Sylvain Corlay wrote:
> My point here was that I don't think that the proposed feature has much to
> do with the concerns that were raised about distutils in general, unless it
> is decided that incremental improvements to the library even backward
> compatible will n
Hi Brett,
On Mon, Aug 29, 2016 at 9:52 PM, Brett Cannon wrote:
>
>
>> As we discussed earlier, even though it is not a concern with C, checking
>> for availability of a compiler flag becomes crucial when building
>> extensions with C++ since new flavors of the language emerge every couple
>> of
11 matches
Mail list logo
