Re: [Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory)

2008-01-21 Thread Brett Cannon
On Jan 21, 2008 1:46 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > What I meant was that we could include an easy_install.py whose sole
> > function is to ensure that setuptools is installed and then invoke
> > the "real" easy_install.  Thus, the first time you ran easy_install,
> > a current version would be downloaded, and thereafter the real one
> > would be runnable.
>
> Despite my (well-known) objections to setuptools as the foundation for
> the .egg format (and everything that comes with it), I think that would
> be a desirable and easy thing to do. Including a setuptools bootstrapper
> into the distribution still leaves the choice of actually using
> setuptools to the end user.

What Martin said, almost verbatim. =)

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory)

2008-01-21 Thread Martin v. Löwis
> What I meant was that we could include an easy_install.py whose sole 
> function is to ensure that setuptools is installed and then invoke 
> the "real" easy_install.  Thus, the first time you ran easy_install, 
> a current version would be downloaded, and thereafter the real one 
> would be runnable.

Despite my (well-known) objections to setuptools as the foundation for
the .egg format (and everything that comes with it), I think that would
be a desirable and easy thing to do. Including a setuptools bootstrapper
into the distribution still leaves the choice of actually using
setuptools to the end user.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory)

2008-01-21 Thread Phillip J. Eby
At 10:48 AM 1/21/2008 -0500, Steve Holden wrote:
>Phillip J. Eby wrote:
> > (Heck, if what you really want is to have easy_install support in
> > 2.6, we could just as easily bundle an easy_install.py that asks for
> > an install of setuptools if it's not already present.)
> >
>Would the easiest way to do this be to insert a default dependency on
>setuptools?

Sorry, I don't understand the question.  What do you mean by "default 
dependency" and to what are you proposing it be inserted?  :)

What I meant was that we could include an easy_install.py whose sole 
function is to ensure that setuptools is installed and then invoke 
the "real" easy_install.  Thus, the first time you ran easy_install, 
a current version would be downloaded, and thereafter the real one 
would be runnable.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory)

2008-01-21 Thread Steve Holden
Phillip J. Eby wrote:
> At 01:06 AM 1/22/2008 +1000, Nick Coghlan wrote:
>> Steve Holden wrote:
>>> Christian Heimes wrote:
 Steve Holden wrote:
> Maybe once we get easy_install as a part of the core (so there's no need
> to find and run ez_setup.py to start with) things will start to improve.
> This is an issue the whole developer community needs to take seriously
> if we are interested in increasing take-up.
 setuptools and easy_install won't be included in Python 2.6 and 3.0:
 http://www.python.org/dev/peps/pep-0365/

>>> Yes, and yet another release (two releases) will go out without easy
>>> access to the functionality in Pypi. PEP 365 is a good start, but Pypi
>>> loses much of its point until new Python users get access to it "out of
>>> the box". I also appreciate that resource limitations are standing in
>>> the way of setuptools' inclusion (is there something I can do about
>>> that?) Just to hammer the point home, however ...
>> Have another look at the rationale given in PEP 365 - it isn't the
>> resourcing to do the work that's a problem, but the relatively slow
>> release cycle of the core.
>>
>> By including pkg_resources in the core (with the addition of access to
>> pure Python modules and packages on PyPI), we would get a simple, stable
>> base for Python packaging to work from, and put users a single standard
>> command away from the more advanced (but also more volatile) features of
>> easy_install and friends.
> 
> By the way, if we're actually going to get that into 2.6, it would be 
> good for the PEP to actually be approved before then.  :)
> 
Yes, I noticed it wasn't yet approved and wondered whether this was 
simply an oversight or whether there is still work to do before it can 
be approved.

> With respect to Steve's comments about out-of-the-box usability, it 
> should be noted that when you bootstrap a package with pkg_resources, 
> it should be possible to include other command-line arguments after 
> the package specifier.  So for example:
> 
>  python -m pkg_resources setuptools SomePackage==1.2
> 
> would download and install setuptools, and run its "bootstrap script" 
> with "SomePackage==1.2" as a command-line argument.  And setuptools' 
> bootstrap script is basically easy_install with some extra code to 
> make sure the setuptools egg gets installed too.
> 
> In other words, with PEP 365 in place, "python -m pkg_resources 
> setuptools" is basically a way to say "easy_install" without needing 
> setuptools installed.
> 
Well that's probably a simple enough recipe to include in the 
distribution, wouldn't you say?

> (Heck, if what you really want is to have easy_install support in 
> 2.6, we could just as easily bundle an easy_install.py that asks for 
> an install of setuptools if it's not already present.)
> 
Would the easiest way to do this be to insert a default dependency on 
setuptools?

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com