On 30 August 2013 00:08, Nick Coghlan wrote:
> We also need to officially bless pip's trick of forcing the use of
> setuptools for distutils based setup.py files.
Do we? What does official blessing imply? We've managed for years without
the trick being "official"...
The main reason it is curre
Nick Coghlan gmail.com> writes:
> We also need to officially bless pip's trick of forcing the use of
> setuptools for distutils based setup.py files.
What does official blessing mean in practice? Is pip to be wedded to
setuptools forever, or might it one day have the possibility of being
impleme
On 30 Aug 2013 17:23, "Paul Moore" wrote:
>
> On 30 August 2013 00:08, Nick Coghlan wrote:
>>
>> We also need to officially bless pip's trick of forcing the use of
setuptools for distutils based setup.py files.
>
>
> Do we? What does official blessing imply? We've managed for years without
the tr
On 29 August 2013 16:49, Paul Moore wrote:
> On 29 August 2013 16:02, Oscar Benjamin wrote:
>>On 29 August 2013 15:30, Antoine Pitrou wrote:
> [...]
>>> (after all, it's just "python setup.py build_bdist", or something :-))
>>
>> The point is that pip and other packaging tools will use 'python
>
On 30 August 2013 12:54, Oscar Benjamin wrote:
> setup.py that would satisfy those commands. It could be as easy as:
>
> if sys.argv[1] == 'bdist_wheel':
> sys.exit(subprocess.call(['bentomaker', 'build_wheel'])
>
> or whatever.
OK, inspiration moment for me. It had never occurred to me tha
On Aug 29, 2013, at 9:33 PM, Richard Jones wrote:
> Hi all,
>
> Given that I believe all outstanding issues with PEP 449 <
> http://python.org/dev/peps/pep-0449/> have been resolved I will accept it in
> its current form (last modified August 16) so the immediate changes may be
> made and pu
On Fri, Aug 30, 2013 at 7:54 AM, Oscar Benjamin
wrote:
> On 29 August 2013 16:49, Paul Moore wrote:
>> On 29 August 2013 16:02, Oscar Benjamin wrote:
>>>On 29 August 2013 15:30, Antoine Pitrou wrote:
>> [...]
(after all, it's just "python setup.py build_bdist", or something :-))
>>>
>>> Th
On 30 August 2013 22:26, Paul Moore wrote:
> On 30 August 2013 12:54, Oscar Benjamin wrote:
>>
>> setup.py that would satisfy those commands. It could be as easy as:
>>
>> if sys.argv[1] == 'bdist_wheel':
>> sys.exit(subprocess.call(['bentomaker', 'build_wheel'])
>>
>> or whatever.
>
>
> OK,
Donald's PEP 453 for explicit pip bootstrapping (by inclusion of a
"getpip" module in the standard library, automatically executed during
installation by the CPython binary installers) is now available on
python.org.
Accordingly, I am now formally rejecting the implicit bootstrapping
proposal that
On 30 August 2013 13:49, Daniel Holth wrote:
> On Fri, Aug 30, 2013 at 7:54 AM, Oscar Benjamin
> wrote:
>>
>> I just tried to install bento to test it out and:
>>
>> $ pip install bento
>> Downloading/unpacking bento
>> Downloading bento-0.1.1.tar.gz (582kB): 582kB downloaded
>> Running setu
Abstract
This PEP proposes the inclusion of a method for explicitly bootstrapping
`pip`_ as the default package manager for Python. It also proposes that the
distributions of Python available via Python.org will automatically run this
explicit bootstrapping method and a recommendation to
On Aug 30, 2013, at 9:44 AM, Donald Stufft wrote:
> [snip]
Available online at http://www.python.org/dev/peps/pep-0453/
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using G
On Aug 30, 2013, at 12:04 PM, Marcus Smith wrote:
> There's no mention of setuptools.
> I guess the handling of that dependency (or not handling it up front, if pip
> is refactored such that setuptools just becomes a dependency when building)
> is considered an implementation detail of get-pi
On 30 August 2013 14:44, Donald Stufft wrote:
> The Windows and OSX installers distributed by Python.org will automatically
> attempt to run ``python -m getpip`` by default however the ``make install``
> and ``make altinstall`` commands of the source distribution will not.
>
Presumably the unins
On Aug 30, 2013, at 11:39 AM, Brett Cannon wrote:
> What about a --without-pip option?
Added this and the grammar mistakes you noted (I suck at this english thing~).
> This should specify if it is ever expected to be kept in the CPython repo
> (and thus distributed in the source tarball) or i
ok, got it. so, theoretically if the pip/setuptools relationship stays
what it is at the moment, get-pip would end up including a bundled
setuptools to fulfill the "Not all users will have network access to PyPI"
On Fri, Aug 30, 2013 at 9:07 AM, Donald Stufft wrote:
>
> On Aug 30, 2013, at 12:
On Aug 30, 2013, at 12:12 PM, Marcus Smith wrote:
> ok, got it. so, theoretically if the pip/setuptools relationship stays what
> it is at the moment, get-pip would end up including a bundled setuptools to
> fulfill the "Not all users will have network access to PyPI"
Yes.
-
On Aug 30, 2013, at 12:32 PM, Marcus Smith wrote:
>
>
> > This should specify if it is ever expected to be kept in the CPython repo
> > (and thus distributed in the source tarball) or if it will simply be
> > bundled in the installers (and thus never included with the source).
>
> Nick may
On Mon, Aug 26, 2013 at 2:25 PM, bharath ravi kumar
wrote:
> Carl, Eby,
>
> Thanks for taking time to suggest various alternatives. Considering that the
> deployment hosts are identical in every as[ect, the approach of moving
> virtualenv's with packages pip-installed at build time appears the sim
> This should specify if it is ever expected to be kept in the CPython repo
> (and thus distributed in the source tarball) or if it will simply be
> bundled in the installers (and thus never included with the source).
>
> Nick may say differently (he's much more "in tune" with what files are
> owne
There's no mention of setuptools.
I guess the handling of that dependency (or not handling it up front, if
pip is refactored such that setuptools just becomes a dependency when
building) is considered an implementation detail of get-pip?
___
Distutils-SIG
On Fri, Aug 30, 2013 at 9:44 AM, Donald Stufft wrote:
> [SNIP]
> Pre-installation
>
>
> During the installation of Python from Python.org ``python -m getpip``
> should
> be executed. Leaving people using the Windows or OSX installers with a
> working
> copy of pip once the instal
Nick Coghlan gmail.com> writes:
>
> On 30 Aug 2013 17:23, "Paul Moore" gmail.com> wrote:
> >
> > On 30 August 2013 00:08, Nick Coghlan gmail.com> wrote:
> >>
> >> We also need to officially bless pip's trick of forcing the use of
setuptools for distutils based setup.py files.
> >
> >
> > Do we?
On 31 Aug 2013 02:02, "Paul Moore" wrote:
>
>
> On 30 August 2013 14:44, Donald Stufft wrote:
>>
>> The Windows and OSX installers distributed by Python.org will
automatically
>> attempt to run ``python -m getpip`` by default however the ``make
install``
>> and ``make altinstall`` commands of the
The admins at g.pypi.python.org/mirror.rit.edu have decided they no
longer have the resources to maintain their mirror. They've already
taken down the content and would like to be removed from any indexes
out there (such as www.pypi-mirrors.org).
-Ralph
___
On Fri, Aug 30, 2013 at 7:18 PM, Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>>
>> On 30 Aug 2013 17:23, "Paul Moore" gmail.com> wrote:
>> >
>> > On 30 August 2013 00:08, Nick Coghlan gmail.com> wrote:
>> >>
>> >> We also need to officially bless pip's trick of forcing the use of
>
DNS and LB config have been updated and should take effect over the next day or
so.
--Noah
On Aug 30, 2013, at 11:01 AM, Ralph Bean wrote:
> The admins at g.pypi.python.org/mirror.rit.edu have decided they no
> longer have the resources to maintain their mirror. They've already
> taken down th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/30/2013 09:57 PM, Daniel Holth wrote:
> One of the most important packaging insights to understand is that
> distutils is in fact worse than setuptools. It is badly outdated,
> poorly extensible, and too complex to ever re-implement in a
> com
28 matches
Mail list logo
