On 05/28/2014 10:02 PM, Barry Warsaw wrote:
> Unfortunately, it's not just six that gets vendorized. I'd be in favor of a
> lintian check if it could be generalized to warn against all vendorizing. A
> warning specifically about six is helpful but limited.
Hi Barry,
How would you implement the
Hi Vincent,
I've commited my changes to the SVN repo. It should be good now. I've
also released and tagged the new version.
Regards,
Hugo
--
Hugo Lefeuvre (hugo6390)|www.hugo6390.org
4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E
signature.asc
Description: Digital si
On May 29, 2014, at 04:47 PM, Thomas Goirand wrote:
>On 05/28/2014 10:02 PM, Barry Warsaw wrote:
>> Unfortunately, it's not just six that gets vendorized. I'd be in favor of a
>> lintian check if it could be generalized to warn against all vendorizing. A
>> warning specifically about six is help
On Thu, May 29, 2014 at 10:53 PM, Barry Warsaw wrote:
> One of the things I want to add to my mythical PEP are at least declarations
> of vendored packages.
What tool do people use to do vendorising? Maybe that could be patched
to include a file containing info about which projects were
vendorise
On May 29, 2014, at 10:58 PM, Paul Wise wrote:
>On Thu, May 29, 2014 at 10:53 PM, Barry Warsaw wrote:
>
>> One of the things I want to add to my mythical PEP are at least declarations
>> of vendored packages.
>
>What tool do people use to do vendorising?
AFAICT it's mostly `$foreignvcs pull; cp -
On Thu, May 29, 2014 at 11:13 PM, Barry Warsaw wrote:
> On May 29, 2014, at 10:58 PM, Paul Wise wrote:
>
>>On Thu, May 29, 2014 at 10:53 PM, Barry Warsaw wrote:
>>
>>> One of the things I want to add to my mythical PEP are at least declarations
>>> of vendored packages.
>>
>>What tool do people use
* Barry Warsaw , 2014-05-29, 10:53:
Unfortunately, it's not just six that gets vendorized. I'd be in
favor of a lintian check if it could be generalized to warn against
all vendorizing. A warning specifically about six is helpful but
limited.
How would you implement the generalization then?
Ye
Hello,
I have prepared a package for python-pandocfilters. AFAIT, it should correspond
to the python packaging guidelines and it builds nicely with Debhelper. BTW,
thanks to the developers and to those who documented the process, great job!
It is Lintian-clean, but I would love to have someone lo
On May 28, 2014, at 12:49 AM, Scott Kitterman wrote:
>Is anyone aware of anything that would prevent dropping python3.3 from
>supported versions as soon as this transition is done?
Nope, let's do it. (I'll see what I can do about helping out with #746709.)
-Barry
signature.asc
Description: P
I'm looking again at updating tox to the latest upstream 1.7.1. Along the
way, I'd like to make /usr/bin/tox a Python 3 script.
This requires that virtualenv be importable, e.g. `$python -m virtualenv`. It
is today in Python 2 since /usr/bin/virtualenv is a Python 2 script and we
only build it f
On May 29, 2014 7:54:53 PM EDT, Barry Warsaw wrote:
>I'm looking again at updating tox to the latest upstream 1.7.1. Along
>the
>way, I'd like to make /usr/bin/tox a Python 3 script.
>
>This requires that virtualenv be importable, e.g. `$python -m
>virtualenv`. It
>is today in Python 2 since /us
On May 29, 2014, at 8:15 PM, Scott Kitterman wrote:
> On May 29, 2014 7:54:53 PM EDT, Barry Warsaw wrote:
>> I'm looking again at updating tox to the latest upstream 1.7.1. Along
>> the
>> way, I'd like to make /usr/bin/tox a Python 3 script.
>>
>> This requires that virtualenv be importable,
On May 29, 2014, at 7:54 PM, Barry Warsaw wrote:
> I'm looking again at updating tox to the latest upstream 1.7.1. Along the
> way, I'd like to make /usr/bin/tox a Python 3 script.
>
> This requires that virtualenv be importable, e.g. `$python -m virtualenv`. It
> is today in Python 2 since /
On May 29, 2014, at 08:15 PM, Scott Kitterman wrote:
>I'd rather remove the wheels we have and give up on ensurepip than start down
>this slippery slope.
That means we give up on pyvenv, and given that virtualenv will eventually be
a wrapper around pyvenv, that means we give up on virtual environ
On May 29, 2014, at 08:30 PM, Donald Stufft wrote:
>Does anything other than tox depend on virtualenv? Unless something python
>2.x depends on virtualenv the only real benefit to having virtualenv
>installed in both 2.x and 3.x is what the default interpreter is whenever you
>create a virtual envi
On May 29, 2014 8:27:07 PM EDT, Donald Stufft wrote:
>
>On May 29, 2014, at 8:15 PM, Scott Kitterman
>wrote:
>
>> On May 29, 2014 7:54:53 PM EDT, Barry Warsaw
>wrote:
>>> I'm looking again at updating tox to the latest upstream 1.7.1.
>Along
>>> the
>>> way, I'd like to make /usr/bin/tox a Pyth
On May 29, 2014, at 08:59 PM, Scott Kitterman wrote:
>I was referring to wheels. It's my understanding that they are primarily for
>platforms without package management.
We use them in the pyvenv solution (and soon in the virtualenv
de-policy-violating solution) because they're the best way (IMHO
Barry Warsaw writes:
> On May 29, 2014, at 08:15 PM, Scott Kitterman wrote:
>
> >I'd rather [Debian] remove the wheels we have and give up on
> >ensurepip than start down this slippery slope.
>
> That means we give up on pyvenv, and given that virtualenv will
> eventually be a wrapper around pyve
On May 29, 2014, at 9:18 PM, Ben Finney wrote:
> Barry Warsaw writes:
>
>> On May 29, 2014, at 08:15 PM, Scott Kitterman wrote:
>>
>>> I'd rather [Debian] remove the wheels we have and give up on
>>> ensurepip than start down this slippery slope.
>>
>> That means we give up on pyvenv, and gi
19 matches
Mail list logo
