[Apologies if this is in the mailing list archives. I looked but didn't
see anything, based on a search for run_setup]
I'm trying to programmatically install something built using distutils. I
found distutils.core.run_setup and can use it via
>>> dist = run_setup('setup.py', ['-q', 'install'])
After reading all this, I really don't believe that adding egg
support to the stdlib at this time is the right thing to do. I am
therefore rejecting the PEP.
I am hoping that someone will create a simpler bootstrap module that
is able to download a file of pure Python code and install it, perhaps
At 05:10 PM 3/17/2008 -0500, Jeff Rush wrote:
>I was in a Packaging BoF yesterday and, although not very relevant to the
>packager bootstrap thread, Guido has asked me to post some of the concerns.
>
>The BoF drew about 15 people, many of whom were packagers for Red Hat, Ubuntu
>and such. Everyone
I was in a Packaging BoF yesterday and, although not very relevant to the
packager bootstrap thread, Guido has asked me to post some of the concerns.
The BoF drew about 15 people, many of whom were packagers for Red Hat, Ubuntu
and such. Everyone had strong expressions of frustration with the s
Folks:
(By the way, it was a pleasure to meet many of you in Real Life for
the first time at Pycon.)
Here is what I want:
1. The standard Python build tools by default produce machine-
parseable package metadata, which can include package dependency
information with reasonably well-defined
On 17/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> That leaves MAL, whose objections to PEP 365 centered on the API (he
> said he was "+1 on the concepts being added to the stdlib, -1 on
> adding the module in its current state"). Among other concerns, he
> wanted pkg_resources to be s
At 02:44 PM 3/17/2008 -0500, Jeff Rush wrote:
>Guido van Rossum wrote:
> > On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> >>
> >> I'm +lots on someone giving a clear explanation of the meaning and
> >> interrelationship of the various terms involved in this discussion
>
Guido van Rossum wrote:
> On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
>>
>> I'm +lots on someone giving a clear explanation of the meaning and
>> interrelationship of the various terms involved in this discussion
>> (setuptools, easy_install, pkg_resources, eggs, "pac
At 01:59 PM 3/17/2008 -0500, Guido van Rossum wrote:
>I have certainly personally encountered plenty of situations where I
>wasn't able to complete an egg-based install because some dependency
>was broken (e.g. not available for the Python version I was using).
That's odd -- setuptools-based insta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
> On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:
>> >I don't think this should play games with scripts being overridden or
>> >whatever. If a
On Mon, Mar 17, 2008 at 1:45 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:59 PM 3/17/2008 -0500, Guido van Rossum wrote:
> >On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby
> ><[EMAIL PROTECTED]> wrote:
> > > At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
> > > >There will be no
At 12:59 PM 3/17/2008 -0500, Guido van Rossum wrote:
>On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby
><[EMAIL PROTECTED]> wrote:
> > At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
> > >There will be no egg support in the standard library.
> >
> > Are there any qualifications on that stat
On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
> >There will be no egg support in the standard library.
>
> Are there any qualifications on that statement, or is this in the
> same category as "from __future__ im
> But I don't see any practical difference with including setuptools and
> including a module that installs setuptools. Would you be happy with
> the standard library including a module whose sole function was to
> install a package that you weren't happy to include directly in the
> standard libra
On 17/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 17, 2008 at 11:55 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> > Is it *wanted* that eggs are being supported by core Python?
>
> No. There will be no egg support in the standard library.
This bothers me somewhat. At a cer
At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote:
>There will be no egg support in the standard library.
Are there any qualifications on that statement, or is this in the
same category as "from __future__ import braces"?
___
Distutils-SIG maillist
On Mon, Mar 17, 2008 at 12:12 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> But I don't see any practical difference with including setuptools and
> including a module that installs setuptools. Would you be happy with
> the standard library including a module whose sole function was to
> install
On Mon, Mar 17, 2008 at 11:55 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > It should be able to download a Python-only module or package and
> > install it into site-packages (or perhaps elsewhere if so directed via
> > another optional command line flag). It should
On 17/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Personally, I have no problem per se with including setuptools in the
> > stdlib. Maybe that means I miss the subtle benefit of this approach...
>
> Did you review setuptools and can vouch that it is written cleanly,
> follows the codi
Guido van Rossum wrote:
> It should be able to download a Python-only module or package and
> install it into site-packages (or perhaps elsewhere if so directed via
> another optional command line flag). It should support zip, tar and
> tar.gz/tgz files (and perhaps tar.bz2). It should simply unpac
> I'm puzzled. We seem to be talking about adding a module to the stdlib
> whose basic function is to download and install setuptools? How is
> this better than just including setuptools in the stdlib?
I can do a review of such a module in an hour. To review setuptools
(which I would have to do if
On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 17/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > >The PEP suggests that other package managers also benefit. How do they
> > >benefit if the bootstrap script installs setuptools?
> >
> > Because those other pa
On 17/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >The PEP suggests that other package managers also benefit. How do they
> >benefit if the bootstrap script installs setuptools?
>
> Because those other package managers depend, in fact, on setuptools,
> or at least pkg_resources... which w
On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:
> >I don't think this should play games with scripts being overridden or
> >whatever. If a bootstrap script is to be installed it should have a
> >separate name. I'm
At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote:
>I don't think this should play games with scripts being overridden or
>whatever. If a bootstrap script is to be installed it should have a
>separate name. I'm not sure what the advantage is of a bootstrap
>script over "python -m bootstrap_module
I don't think this should play games with scripts being overridden or
whatever. If a bootstrap script is to be installed it should have a
separate name. I'm not sure what the advantage is of a bootstrap
script over "python -m bootstrap_module ..." though.
The PEP suggests that other package manage
>> I thought the original proposal was to install a *binary* easy_install
>> that takes that function.
>
> What do you mean by "binary"? I thought we were talking about a
> module. Do you mean a script to be installed alongside Python itself in
> e.g. /usr/bin?
Exactly so.
> In the original
At 09:45 AM 3/17/2008 -0500, Martin v. Löwis wrote:
> > Well, it might be replaced by a protracted discussion of how the
> > module should work and what its API should be, but perhaps that would
> > be a better one to have. :)
>
>Indeed, that's likely to happen :-)
>
> > So, the original proposal
> Well, it might be replaced by a protracted discussion of how the
> module should work and what its API should be, but perhaps that would
> be a better one to have. :)
Indeed, that's likely to happen :-)
> So, the original proposal (from the previous thread about this) was
> that the module
At 08:48 AM 3/17/2008 -0500, Guido van Rossum wrote:
>On Sun, Mar 16, 2008 at 7:06 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > So, if the consensus is that it would be better to have a module that
> > only does bootstrap installs of pure-Python eggs from PyPI, I'm
> > totally fine with tha
On Sun, Mar 16, 2008 at 7:06 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> So, if the consensus is that it would be better to have a module that
> only does bootstrap installs of pure-Python eggs from PyPI, I'm
> totally fine with that.
Let's just do this; it will avoid a protracted discussio
31 matches
Mail list logo
