Paul Moore wrote:
> Is there anything I can do to get it applied, or should I just leave
> it now for someone to decide if they care enough? (As it's a library
> change, I don't know to what extent the "no API changes after the next
> alpha" rule will apply).
I'm looking into it now - assuming it
On 19/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I'm currently working on an addition to pkgutil to provide this type
> > of function. I'm considering going a little further (adding functions
> > to get a file-like object, test for existence, and list available
> > resources, mode
On Mar 20, 2008, at 11:31 AM, Martin v. Löwis wrote:
>> I'll note that I use easy_install *only* to work in *non-system*
>> locations: if I want to install Python packages to /usr/lib/
>> python2.x/,
>> I use the standard system installer, e.g. 'apt-get install
>> python-frobnatz'.
>
> This is p
On 20/03/2008, Jeff Rush <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > On 20/03/2008, zooko <[EMAIL PROTECTED]> wrote:
> > 1. No integration with the system packager (Windows, in my case). If I
> > do easy_install nose, then nose does not show up in add/remove
> > programs. That significan
Paul Moore wrote:
> On 20/03/2008, zooko <[EMAIL PROTECTED]> wrote:
> I'll chime in here, too. I really want to like
> setuptools/easy_install, but I don't. I'll try to be specific in my
> reasons, in the hope that they can be addressed. I know some of these
> are "known about", but one of my meta
On 19/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'd only do what __loader__ offers. People can always wrap a StringIO around
> it.
>
> > Once I have a patch, I'll post it to the tracker. What's the best
> > approach? Code a patch for 3.0 and backport, or code for 2.6 and let
> >
> although the word "trove" means nothing to me
http://www.askoxford.com/concise_oed/trove?view=uk
"a store of valuable or delightful things"
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
On Wed, 2008-03-19 at 22:18 -0600, zooko wrote:
> 1. "The very notion of package dependency resolution and
> programmable or command-line installation of packages at the language
> level is a bad notion."
>
> This can't really be the case. If the existence of such
> functionality at the pr
On Wed, Mar 19, 2008 at 11:34 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 19/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Mon, Mar 17, 2008 at 2:19 PM, zooko <[EMAIL PROTECTED]> wrote:
> > > 4. The standard Python library includes a tool to find and read
> > > resources (o
On 19/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 17, 2008 at 2:19 PM, zooko <[EMAIL PROTECTED]> wrote:
> > 4. The standard Python library includes a tool to find and read
> > resources (other than Python modules) that came bundled in a Python
> > package.
>
> I think
On Mon, Mar 17, 2008 at 2:19 PM, zooko <[EMAIL PROTECTED]> wrote:
> 4. The standard Python library includes a tool to find and read
> resources (other than Python modules) that came bundled in a Python
> package.
>
> Consider, for example, this snippets of code in Nevow:
>
> http://divmod.org
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
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
> 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 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 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
> 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
20 matches
Mail list logo
