|
Email lists >
Python developers >
Re: [Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory) >
Re: [Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory)
Re: [Python-Dev] PEP 365 (was Re: PEP: per user site-packages directory)
This post if a part of this thread
|
2008-01-21 09:48:02 |
|
|
Re: PEP 365 (was Re: PEP: per user site-packages directory)
|
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.p
ython.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/
a>
_______________________________________________
Python-Dev mailing list
Python-Dev python.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com
|
|
|
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|