On 10 November 2015 at 16:14, Nick Coghlan wrote:
> On 30 October 2015 at 16:27, Marcus Smith wrote:
>>>
>>> =
>>> Whenever a new PEP is put forward on distutils-sig, any PyPA core
>>> reviewer that believes they are suitably experienced to make the final
>>> decis
On 30 October 2015 at 16:27, Marcus Smith wrote:
>>
>> =
>> Whenever a new PEP is put forward on distutils-sig, any PyPA core
>> reviewer that believes they are suitably experienced to make the final
>> decision on that PEP may offer to serve as the BDFL's delegate
this reads ok to me...
On Sun, Nov 8, 2015 at 9:20 PM, Nathaniel Smith wrote:
> Hi all,
>
> Following the strategy of trying to break out the different
> controversial parts of the new build system interface, here's some
> proposed text defining the environment that a build frontend like pip
> p
btw, I'm very aware that recent discussions may be changing the roadmap...
: )
I'm holding fast for the smoke to clear...
On Wed, Nov 4, 2015 at 4:42 PM, Marcus Smith wrote:
> FYI, I went ahead and merged it.
>
> https://www.pypa.io/en/latest/roadmap/
>
> Again, help appreciated from anyone
> Because even if we go with the entry-point-style Python
> hooks, the build frontends like pip will still want to spawn a child
> to do the actual calls -- this is important for isolating pip from the
> build backend and the build backend from pip, it's important because
> the build backend needs
On 10 November 2015 at 15:03, Nathaniel Smith wrote:
> On Sun, Nov 8, 2015 at 5:28 PM, Robert Collins
> wrote:
>> +The use of a command line API rather than a Python API is a little
>> +contentious. Fundamentally anything can be made to work, and Robert wants to
>> +pick something thats sufficien
On Sun, Nov 8, 2015 at 5:28 PM, Robert Collins
wrote:
> +The use of a command line API rather than a Python API is a little
> +contentious. Fundamentally anything can be made to work, and Robert wants to
> +pick something thats sufficiently lowest common denominator that
> +implementation is strai
On Mon, Nov 9, 2015 at 5:20 PM, Ionel Cristian Mărieș
wrote:
>
> On Tue, Nov 10, 2015 at 3:05 AM, Nathaniel Smith wrote:
>>
>> So apparently if you use 'python -m venv' to create a new *venv* while
>> inside a *virtualenv*, then it seems to complete successfully but
>> leaves you with a venv that
On Tue, Nov 10, 2015 at 3:05 AM, Nathaniel Smith wrote:
> So apparently if you use 'python -m venv' to create a new *venv* while
> inside a *virtualenv*, then it seems to complete successfully but
> leaves you with a venv that doesn't contain pip. At least on my
> machine (up-to-date Debian testi
On Thu, Nov 5, 2015 at 7:52 PM, Glyph Lefkowitz wrote:
>
> If you invoke 'pip[X.Y]' and it matches 'python -m pip' in your current
> virtualenv, don't say anything; similarly if you invoke 'python -m pip' and
> 'which pip' matches. But if there's a mismatch, pip can print information
> in both ca
On Sun, Nov 8, 2015 at 8:01 AM, Ionel Cristian Mărieș
wrote:
>
> On Sat, Nov 7, 2015 at 12:24 AM, Donald Stufft wrote:
>>
>> Well, it’s not really a launcher no, but you’d do ``pip -p python2 install
>> foo`` or something like that. It’s the same UI. Having just a “launcher” I
>> think is actuall
On November 9, 2015 at 8:05:29 PM, Nathaniel Smith (n...@pobox.com) wrote:
> > This is "just a bug", but it seems fair to assume that there will
> continue to exist some weird corner-case bugs in Python
> packaging/distribution/environment-creation for a while
> yet…
Note: I think my PoC will
On Mon, Nov 9, 2015 at 3:28 PM, Chris Barker wrote:
> On Sat, Nov 7, 2015 at 3:53 PM, Antoine Pitrou wrote:
>>
>> Well, the problem is that "python -m pip" isn't any better. If you
>> don't know what the current "pip" is, then chances are you don't know
>> what the current "python" is, either.
>
Thanks for your quick answer! Let's hope Fastly will deploy IPv6 soon, then.
Baptiste
On Sun, Nov 08, 2015 at 09:13:49PM -0500, Donald Stufft wrote:
> I’m pretty sure that PyPI will get IPv6 support as soon as Fastly supports it
> and not any sooner. I know they’re working on making it happen b
On Mon, Nov 9, 2015 at 3:27 AM, James Bennett wrote:
> Python scripts directly and without having to do hackery with
> supporting/requiring 'python -m' or similar is too useful and commonly
> used. So faced with either (essentially) forcing a trend of every
> command-line tool having to be invoke
On Sat, Nov 7, 2015 at 3:53 PM, Antoine Pitrou wrote:
> Well, the problem is that "python -m pip" isn't any better. If you
> don't know what the current "pip" is, then chances are you don't know
> what the current "python" is, either.
>
sure you do (well, maybe not, but all you know is that when
wow! a really long thread here. Trying not to duplicate too much. I am
coming primarily from the perspective of someone that teaches python to
beginners (I'm also a user and package developer, but I, myself, can deal
with any of these options...)
My perspective as a user of pip, but not a develope
Pushed up this edit..
On 9 November 2015 at 18:45, Robert Collins wrote:
> On 9 November 2015 at 17:55, Nathaniel Smith wrote:
>> The new version is looking pretty good to me!
>>
>> My main concern still is that specification of whitespace handling is
>> still kinda confusing/underspecified. The
On 9 November 2015 at 17:21, Nathaniel Smith wrote:
> On Mon, Nov 9, 2015 at 7:34 AM, Paul Moore wrote:
>> On 9 November 2015 at 05:20, Nathaniel Smith wrote:
>>> A *source tree* is something like a VCS checkout. We need a standard
>>> interface for installing from this format, to support usages
On Mon, Nov 9, 2015 at 7:34 AM, Paul Moore wrote:
> On 9 November 2015 at 05:20, Nathaniel Smith wrote:
>> A *source tree* is something like a VCS checkout. We need a standard
>> interface for installing from this format, to support usages like
>> ``pip install some-directory/``.
>
> I still find
Sometimes it might be desirable to do wheel-like installs without actually
creating an archive. Instead, a whim (wheel internal manifest) file could
communicate the idea of wheel, just a bunch of files in categories, without
the zip file.
The format would be no more than a mapping of category name
On November 9, 2015 at 10:35:24 AM, Paul Moore (p.f.mo...@gmail.com) wrote:
> On 9 November 2015 at 05:20, Nathaniel Smith wrote:
> > A *source tree* is something like a VCS checkout. We need a standard
> > interface for installing from this format, to support usages like
> > ``pip install some-dir
On 9 November 2015 at 05:20, Nathaniel Smith wrote:
> A *source tree* is something like a VCS checkout. We need a standard
> interface for installing from this format, to support usages like
> ``pip install some-directory/``.
I still find these two definitions unhelpful, sorry.
We don't *need* a
On November 9, 2015 at 8:26:50 AM, Paul Moore (p.f.mo...@gmail.com) wrote:
> On 9 November 2015 at 12:46, Wayne Werner wrote:
> > My experience(s) with the latest IPython is that it's freaking magic - in
> > a good way :)
>
> Nice :-) Maybe pip could learn something useful from how the IPython
>
On 9 November 2015 at 12:46, Wayne Werner wrote:
> My experience(s) with the latest IPython is that it's freaking magic - in
> a good way :)
Nice :-) Maybe pip could learn something useful from how the IPython
guys do that.
Paul
___
Distutils-SIG mailli
On November 9, 2015 at 6:17:41 AM, Oscar Benjamin (oscar.j.benja...@gmail.com)
wrote:
> On 9 November 2015 at 10:44, Wolfgang Maier
> wrote:
> >
> > Something I miss in all the discussions taking place here is the fact that
> > python -m pip is the officially documented way of invoking pip at
> >
On Mon, Nov 9, 2015 at 6:01 AM, Paul Moore wrote:
>
> The one thing that *is* special about pip is that it actually
> *modifies* the Python installation it runs under. So running pip with
> the "wrong" Python makes persistent changes somewhere you weren't
> expecting. Whereas running the wrong Dj
On November 9, 2015 at 7:01:57 AM, Paul Moore (p.f.mo...@gmail.com) wrote:
>
> This is pretty much why I said earlier that this isn't really a pip
> issue. It applies just as much to Django, to pydoc, etc.
>
> I'm concerned that what is happening at the moment is that every
> project implements
On Mon, 9 Nov 2015 12:01:37 +
Paul Moore wrote:
>
> The one thing that *is* special about pip is that it actually
> *modifies* the Python installation it runs under.
Fortunately, though, if you are running the system pip without having
root privileges activated, it will most certainly fail w
On Mon, 9 Nov 2015 11:16:56 +
Oscar Benjamin wrote:
> On 9 November 2015 at 10:44, Wolfgang Maier
> wrote:
> >
> > Something I miss in all the discussions taking place here is the fact that
> > python -m pip is the officially documented way of invoking pip at
> > https://docs.python.org/3/ins
On 9 November 2015 at 11:27, James Bennett wrote:
> I agree with this, and with the feeling that we're just kicking the failure
> down the line: if someone doesn't know what Python is being invoked by
> 'pip', they likely will have the same problem with other tools, too, and
> ultimately the abili
On Sunday, November 8, 2015, Ben Finney wrote:
>
> +1. Addressing this by insisting on ‘python -m foo’ is not a solution.
> It's a plaster over a problem that will remain until the underlying
> conflict is resolved.
>
> That's not to say PyPA should ignore the issue, certainly there are
> things t
On 9 November 2015 at 10:44, Wolfgang Maier
wrote:
>
> Something I miss in all the discussions taking place here is the fact that
> python -m pip is the officially documented way of invoking pip at
> https://docs.python.org/3/installing/index.html#basic-usage and it is not
> particularly helpful i
On 09.11.2015 02:13, Donald Stufft wrote:
On November 5, 2015 at 4:08:56 PM, Donald Stufft (don...@stufft.io) wrote:
Another possible option is to modify pip so that instead of installing into
site-packages we instead create an "executable zip file" which is a simple zip
file that has all of pi
34 matches
Mail list logo
