On Wed, Mar 27, 2013 at 6:42 AM, Erik Bray wrote:
> I pretty much agree with you on all of this, but I don't think the
> question should be ignored either--avoiding this question is one of
> the things that got previous packaging reform efforts into trouble.
> Though the agreement to treat "build"
On Tue, Mar 26, 2013 at 12:46 PM, Daniel Holth wrote:
> On Tue, Mar 26, 2013 at 11:45 AM, Erik Bray wrote:
>> On Mon, Mar 25, 2013 at 1:23 PM, Daniel Holth wrote:
>>> My vision for the setuptools deprecation process is that distutils
>>> rides into the sunset with it. In this future eventually b
On Tue, Mar 26, 2013 at 12:46 PM, Daniel Holth wrote:
> I suspect at least 80% of packages will use some simple thing that
> comes with Python, two third party build tools will dominate, and we
> will discover interesting things that just weren't possible before. At
> least if someone wants to imp
On Tue, Mar 26, 2013 at 11:45 AM, Erik Bray wrote:
> On Mon, Mar 25, 2013 at 1:23 PM, Daniel Holth wrote:
>> My vision for the setuptools deprecation process is that distutils
>> rides into the sunset with it. In this future eventually bugs in
>> setuptools will be solved by porting setup.py to o
On Tue, Mar 26, 2013 at 11:21 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/26/2013 05:28 AM, Ronald Oussoren wrote:
>>
>> On 25 Mar, 2013, at 19:16, PJ Eby wrote:
>>>
>>>
>>> Also, as far as detecting the need for setuptools, I think that can
>>> be done just
On Tue, Mar 26, 2013 at 11:54 AM, Erik Bray wrote:
> I don't think "downloading the installer" should be a side effect of
> running the installation either, but until this mess is cleaned up
> it's a necessary evil. Yes, making things easier for users who don't
> know what they're doing is a legi
On 26 Mar, 2013, at 16:21, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/26/2013 05:28 AM, Ronald Oussoren wrote:
>>
>> On 25 Mar, 2013, at 19:16, PJ Eby wrote:
>>>
>>>
>>> Also, as far as detecting the need for setuptools, I think that can
>>> be done just
On Mon, Mar 25, 2013 at 1:23 PM, Daniel Holth wrote:
> My vision for the setuptools deprecation process is that distutils
> rides into the sunset with it. In this future eventually bugs in
> setuptools will be solved by porting setup.py to one of (X, Y, Z)
> which haven't necessarily been invented
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/26/2013 05:28 AM, Ronald Oussoren wrote:
>
> On 25 Mar, 2013, at 19:16, PJ Eby wrote:
>>
>>
>> Also, as far as detecting the need for setuptools, I think that can
>> be done just by noticing whether the PKG-INFO included in an sdist
>> is met
> Just assuming that every sdist with old metadata requires setuptools would
> work, although it will be strange to see that some packages @work that use
> plain disutils suddenly seem to require setuptool :-)
pip does this already, importing setuptools before running any setup.py
>> These impr
On 26 Mar, 2013, at 13:27, Daniel Holth wrote:
> stall themselves, they can just mention setup-requires and the installer
> grabs the necessary setuptools.
> > >
> > That can only be done for sdists with 2.0 metadata, sdists for older
> > versions don't have a setup-requires in their metadata.
On Mar 26, 2013 7:26 AM, "Ronald Oussoren" wrote:
>
>
> On 26 Mar, 2013, at 12:06, Daniel Holth wrote:
>
> >
> > On Mar 26, 2013 5:28 AM, "Ronald Oussoren"
wrote:
> > >
> > >
> > > On 25 Mar, 2013, at 19:16, PJ Eby wrote:
> > > >
> > > >
> > > > Also, as far as detecting the need for setuptools
On 26 Mar, 2013, at 12:06, Daniel Holth wrote:
>
> On Mar 26, 2013 5:28 AM, "Ronald Oussoren" wrote:
> >
> >
> > On 25 Mar, 2013, at 19:16, PJ Eby wrote:
> > >
> > >
> > > Also, as far as detecting the need for setuptools, I think that can be
> > > done just by noticing whether the PKG-INFO i
On Mar 26, 2013 5:28 AM, "Ronald Oussoren" wrote:
>
>
> On 25 Mar, 2013, at 19:16, PJ Eby wrote:
> >
> >
> > Also, as far as detecting the need for setuptools, I think that can be
> > done just by noticing whether the PKG-INFO included in an sdist is
> > metadata 2.0 or not. If it is, then setup
On 25 Mar, 2013, at 19:16, PJ Eby wrote:
>
>
> Also, as far as detecting the need for setuptools, I think that can be
> done just by noticing whether the PKG-INFO included in an sdist is
> metadata 2.0 or not. If it is, then setuptools should be explicitly
> declared as a build-time dependency
I created a pip issue for this
https://github.com/pypa/pip/issues/863
On Mon, Mar 25, 2013 at 9:42 AM, Nick Coghlan wrote:
> On Mon, Mar 25, 2013 at 9:23 AM, Nick Coghlan wrote:
> > This can be handled in pip, by using the AST module to scan for
> > setuptools imports in setup.py (or else by ch
On Mon, Mar 25, 2013 at 1:23 PM, Daniel Holth wrote:
> It is going to be problematic to try to find and download legacy eggs
> correctly and automatically since they don't for example tell you
> whether they are wide Unicode. Those problems and more would apply to
> automatically downloading and c
On Mon, Mar 25, 2013 at 12:50 PM, Nick Coghlan wrote:
> On Mon, Mar 25, 2013 at 9:42 AM, Marcus Smith wrote:
>>
>>>
>>> The *only* case this approach doesn't immediately cover is a project that:
>>> 1. Doesn't publish a pre-built wheel for the current platform (or egg,
>>> assuming pip gains supp
25 March 2013 03:49, Richard Jones wrote:
> On 25 March 2013 14:11, Nick Coghlan wrote:
>> On 3/24/13, Richard Jones wrote:
>>> This is a valid concern. Obviously "pip install easy_install" is not a
>>> solution - especially since the general intention is to deprecate
>>> easy_install eventuall
On Mon, Mar 25, 2013 at 9:42 AM, Marcus Smith wrote:
>
>>
>> The *only* case this approach doesn't immediately cover is a project that:
>> 1. Doesn't publish a pre-built wheel for the current platform (or egg,
>> assuming pip gains support for those, perhaps by implicitly converting
>> them to whe
On Mon, Mar 25, 2013 at 9:23 AM, Nick Coghlan wrote:
> This can be handled in pip, by using the AST module to scan for
> setuptools imports in setup.py (or else by checking for a setuptools
> related ImportError after trying to run it). Yes, it's a hack, but I
> am *not* going to approve a PEP tha
>
> The *only* case this approach doesn't immediately cover is a project that:
> 1. Doesn't publish a pre-built wheel for the current platform (or egg,
> assuming pip gains support for those, perhaps by implicitly converting
> them to wheels)
> 2. Doesn't publish 2.0 metadata with "Setup-Requires-D
On Sun, Mar 24, 2013 at 8:49 PM, Richard Jones
wrote:
> I think we have too much legacy to support here. Sure it'd be nice if
> everyone just switched over to PEP 426 style overnight, but it ain't
> gonna happen. The intent of the automatic setuptools installation is
> to mirror the *current* situ
> I had thrown around the idea of the pip bootstrap installing both pip
> implementation *and* setuptools. At the time my justification was that
> pip depended on it. The pip devs have indicated that they could remove
> the setuptools dependency when distlib and wheel support are in the
> Python st
Wheels are very similar to eggs. The initial wheel implementation
converts *every* newly built wheel from .egg-info to .dist-info since
setuptools doesn't know how to generate the new metadata. I think you
will find the conversion to be reliable, though it can't download the
eggs for you right now.
On 25 March 2013 14:11, Nick Coghlan wrote:
> On 3/24/13, Richard Jones wrote:
>> This is a valid concern. Obviously "pip install easy_install" is not a
>> solution - especially since the general intention is to deprecate
>> easy_install eventually (as explained in Nick's response). I did not
>>
On 3/24/13, Richard Jones wrote:
> This is a valid concern. Obviously "pip install easy_install" is not a
> solution - especially since the general intention is to deprecate
> easy_install eventually (as explained in Nick's response). I did not
> discuss eggs with the pip developers while at PyCon
On 24 March 2013 20:48, holger krekel wrote:
> backward compat with present-day release files: the PEP should state
> it as a goal or at least discuss it in some depth. In that context, the
> choice of providing a bootstrap for pip rather than easy_install needs
> reasoning. One problem with pip
On Sun, Mar 24, 2013 at 09:04 -0700, Nick Coghlan wrote:
> On Sun, Mar 24, 2013 at 2:48 AM, holger krekel wrote:
> > Hi Richard, all,
> >
> > two first notes on PEP439.
>
> PEP 439 is just one small piece of a much larger puzzle, and the
> entire puzzle won't be explained in this PEP. I realise t
On Sun, Mar 24, 2013 at 2:48 AM, holger krekel wrote:
> Hi Richard, all,
>
> two first notes on PEP439.
PEP 439 is just one small piece of a much larger puzzle, and the
entire puzzle won't be explained in this PEP. I realise this makes it
hard to evaluate in isolation, but the beta freeze for 3.4
On Sun, Mar 24, 2013 at 09:49 -0400, Daniel Holth wrote:
> Did you know that the "wheel convert" command masks wheels from eggs?
Wasn't aware, thanks for the pointer. That should certainly be part of
the PEP439 discussion i ask for in the first paragraph.
holger
> On Mar 24, 2013 5:48 AM, "holg
Did you know that the "wheel convert" command masks wheels from eggs?
On Mar 24, 2013 5:48 AM, "holger krekel" wrote:
> Hi Richard, all,
>
> two first notes on PEP439.
>
> backward compat with present-day release files: the PEP should state
> it as a goal or at least discuss it in some depth. In
Hi Richard, all,
two first notes on PEP439.
backward compat with present-day release files: the PEP should state
it as a goal or at least discuss it in some depth. In that context, the
choice of providing a bootstrap for pip rather than easy_install needs
reasoning. One problem with pip, compa
33 matches
Mail list logo
