Next iteration:
diff --git a/dependency-specification.rst b/dependency-specification.rst
index d60df6e..72a87f1 100644
--- a/dependency-specification.rst
+++ b/dependency-specification.rst
@@ -117,7 +117,8 @@ environments::
Optional components of a distribution may be specified using the extras
On Wed, Nov 11, 2015 at 11:34 AM, Paul Moore wrote:
> On 11 November 2015 at 18:38, Nathaniel Smith wrote:
>> Have you tried current dev versions of pip recently?
>
> No, but I did see your work on this, and I appreciate and approve of it.
>
>> The default now is to
>> suppress the actual output
On 11 November 2015 at 19:31, Nathaniel Smith wrote:
> This particular subthread is all hanging off of Paul's message [1]
> where he argues that we can't just print arbitrary text to
> stdout/stderr, we need, like, structured JSON messages on stdout that
> pip can parse while the build is running
On 11 November 2015 at 18:38, Nathaniel Smith wrote:
> Have you tried current dev versions of pip recently?
No, but I did see your work on this, and I appreciate and approve of it.
> The default now is to
> suppress the actual output but for progress reporting to show a spinner that
> rotates ea
On Wed, Nov 11, 2015 at 11:12 AM, Robert Collins
wrote:
> On 12 November 2015 at 08:07, Nathaniel Smith wrote:
>> On Wed, Nov 11, 2015 at 10:42 AM, Donald Stufft wrote:
>>> On November 11, 2015 at 1:38:38 PM, Nathaniel Smith (n...@pobox.com) wrote:
> Guaranteeing a clean stdout/stderr is ha
On Wed, Nov 11, 2015 at 4:29 AM, Donald Stufft wrote:
> On November 11, 2015 at 4:05:11 AM, Nathaniel Smith (n...@pobox.com) wrote:
>> > But even this isn't really true -- the difference between them
>> is that
>> either way you have a subprocess API, but with a Python API, the
>> subprocess inter
On 12 November 2015 at 03:48, Donald Stufft wrote:
...
> Right. I think PEP 426 fell into the same trap that distutils2 fell into. It
> attempted to boil the ocean in one step and the longer it went on the more
> aspirational stuff got layered onto it because it was being held up as the
> great
On November 11, 2015 at 2:08:00 PM, Nathaniel Smith (n...@pobox.com) wrote:
> On Wed, Nov 11, 2015 at 10:42 AM, Donald Stufft wrote:
> > On November 11, 2015 at 1:38:38 PM, Nathaniel Smith (n...@pobox.com) wrote:
> >> > Guaranteeing a clean stdout/stderr is hard: it means you have
> >> to be carefu
On 12 November 2015 at 08:07, Nathaniel Smith wrote:
> On Wed, Nov 11, 2015 at 10:42 AM, Donald Stufft wrote:
>> On November 11, 2015 at 1:38:38 PM, Nathaniel Smith (n...@pobox.com) wrote:
>>> > Guaranteeing a clean stdout/stderr is hard: it means you have
>>> to be careful to correctly capture a
On Wed, Nov 11, 2015 at 10:42 AM, Donald Stufft wrote:
> On November 11, 2015 at 1:38:38 PM, Nathaniel Smith (n...@pobox.com) wrote:
>> > Guaranteeing a clean stdout/stderr is hard: it means you have
>> to be careful to correctly capture and process the output of every
>> child you invoke (e.g. co
On Nov 11, 2015 12:31 PM, "Robert Collins"
wrote:
>
> On 12 November 2015 at 02:30, Paul Moore wrote:
> > On 10 November 2015 at 22:44, Nathaniel Smith wrote:
> >> "Stdin is unspecified, and stdout/stderr can be used for printing
> >> status messages, errors, etc. just like you're used to from e
On November 11, 2015 at 1:38:38 PM, Nathaniel Smith (n...@pobox.com) wrote:
> > Guaranteeing a clean stdout/stderr is hard: it means you have
> to be careful to correctly capture and process the output of every
> child you invoke (e.g. compilers), and deal correctly with the
> tricky aspects
On Nov 11, 2015 5:30 AM, "Paul Moore" wrote:
>
> On 10 November 2015 at 22:44, Nathaniel Smith wrote:
> > "Stdin is unspecified, and stdout/stderr can be used for printing
> > status messages, errors, etc. just like you're used to from every
> > other build system in the world."
>
> This is over
On 12 November 2015 at 02:30, Paul Moore wrote:
> On 10 November 2015 at 22:44, Nathaniel Smith wrote:
>> "Stdin is unspecified, and stdout/stderr can be used for printing
>> status messages, errors, etc. just like you're used to from every
>> other build system in the world."
>
> This is over si
We just pushed devpi-{server,web,client,common} release files out to pypi.
Most notably, the private pypi package server allows much faster installs
due to much improved simple-page serving speed. See the changelog
below for a host of other changes and fixes as well as for compatibility
warnings.
On 11 November 2015 at 14:48, Donald Stufft wrote:
> Right. I think PEP 426 fell into the same trap that distutils2 fell into. It
> attempted to boil the ocean in one step and the longer it went on the more
> aspirational stuff got layered onto it because it was being held up as the
> great hop
On November 11, 2015 at 9:34:41 AM, Nick Coghlan (ncogh...@gmail.com) wrote:
> On 11 November 2015 at 15:08, Wayne Werner wrote:
> >
> > With all of the weirdness involved, it makes me wonder - could there be a
> > better way? If we waved our hands and were able to magically make Python
> > package
On 11 November 2015 at 15:08, Wayne Werner wrote:
>
> With all of the weirdness involved, it makes me wonder - could there be a
> better way? If we waved our hands and were able to magically make Python
> package management perfect, what would that look like?
>
> Would that kind of discussion even
On Nov 10, 2015 11:09 PM, "Wayne Werner" wrote:
>
>
> With all of the weirdness involved, it makes me wonder - could there be a
better way? If we waved our hands and were able to magically make Python
package management perfect, what would that look like?
>
> Would that kind of discussion even be
On 10 November 2015 at 22:44, Nathaniel Smith wrote:
> "Stdin is unspecified, and stdout/stderr can be used for printing
> status messages, errors, etc. just like you're used to from every
> other build system in the world."
This is over simplistic.
We have real-world requirements from users of
On November 11, 2015 at 7:51:05 AM, Steve Dower (steve.do...@python.org) wrote:
> As much as I dislike sniping into threads like this, my gut feeling is
> strongly pushing
> towards defining the Python interface in the PEP and keeping command line
> interfaces
> as private.
>
> I don't have
On November 11, 2015 at 1:30:57 AM, Thomas Güttler
(guettl...@thomas-guettler.de) wrote:
>
> Maybe I am missing something, but still think server side dependency
> resolution is possible.
>
I don’t believe it’s possible nor desirable to have the server handle
dependency resolution, at lea
As much as I dislike sniping into threads like this, my gut feeling is strongly
pushing towards defining the Python interface in the PEP and keeping command
line interfaces as private.
I don't have any new evidence, but pickle and binary stdio (not to mention
TCP/HTTP for doing things remotely)
#PythonPackageBuildEnvironment
...
* pip-tools: https://github.com/nvie/pip-tools
* "are there updates?"
* "which updates would there be?"
* devpi: https://bitbucket.org/hpk42/devpi/
* "where do we push these?"
* "does it build (do the included package tests pass)?"
"does it build (do th
On 11 November 2015 at 06:35, Nick Coghlan wrote:
>
> Longer term, it may even make sense to take the "python" command on
> *nix systems in that direction, or, at the very least, make "py" a
> cross-platform invocation technique:
> https://mail.python.org/pipermail/linux-sig/2015-October/00.ht
On November 11, 2015 at 4:05:11 AM, Nathaniel Smith (n...@pobox.com) wrote:
> > But even this isn't really true -- the difference between them
> is that
> either way you have a subprocess API, but with a Python API, the
> subprocess interface that pip uses has the option of being improved
> i
On 11 November 2015 at 06:35, Nick Coghlan wrote:
> Windows Python 2 installations require manual PATH modifications
> regardless, but it's more common for people to know how to make
> "python -m pip install X" work, than it is for them to remember to
> also add the "Scripts" directory needed to m
In case it's useful to make this discussion more concrete, here's a
sketch of what the pip code for dealing with a build system defined by
a Python API might look like:
https://gist.github.com/njsmith/75818a6debbce9d7ff48
Obviously there's room to build on this to get much fancier, but
AFAICT
On Tue, Nov 10, 2015 at 11:27 PM, Robert Collins
wrote:
> On 11 November 2015 at 19:49, Nick Coghlan wrote:
>> On 11 November 2015 at 16:19, Robert Collins
>> wrote:
> ...>> pip is going to be invoking a CLI *no matter what*. Thats a hard
>>> requirement unless Python's very fundamental import
29 matches
Mail list logo
