[EMAIL PROTECTED] wrote:
> Martin> c) ask for consent in advance to making a potentially-breaking
> Martin>change.
>
> Doesn't that potentially extend the release time for an enhanced distutils
> across multiple Python releases?
Yes, but your alternative doesn't "scale" over time. At
Martin> c) ask for consent in advance to making a potentially-breaking
Martin>change.
Doesn't that potentially extend the release time for an enhanced distutils
across multiple Python releases? With both distutils and setuptools
available simultaneously, setuptools can be designed an
Phillip J. Eby wrote:
> I assumed that it would be more controversial to merge setuptools into
> distutils, than to provide it as an enhanced alternative.
It is this assumption in setuptools that seems to have guided many
design decisions: that it is completely unacceptable to change
implementati
At 11:36 PM 4/19/2006 +0200, Fredrik Lundh wrote:
>Phillip J. Eby wrote:
>
> > >a technical document that, in full detail, describes the mechanisms
> *used* by
> > >setuptools, including what files it creates, what the files contain, how
> > >they are used during import, how non-setuptools code ca
Phillip J. Eby wrote:
> >a technical document that, in full detail, describes the mechanisms *used* by
> >setuptools, including what files it creates, what the files contain, how
> >they are used during import, how non-setuptools code can manipulate (or at
> > least inpect) the data, etc, setuptoo
At 08:33 PM 4/19/2006 +0200, Ronald Oussoren wrote:
>Have you considered such a merger? It's rather odd to include a
>package in
>the stdlib that monkeypatches another part of the stdlib.
I assumed that it would be more controversial to merge setuptools into
distutils, than to provide it as an en
On 18-apr-2006, at 23:10, Phillip J. Eby wrote:
>
>> There aren't all that many things that are wrong in setuptools,
>> but some of them are essential:
>>
>> * setuptools should not monkey patch distutils on import
>
> Please propose an alternative, or better still, produce a patch.
> Be sure
>
At 08:38 AM 4/19/2006 +0200, Fredrik Lundh wrote:
>I'm -1 on adding tools to the core that changes the structure of an installed
>Python system, without a full PEP process. If nobody can point to (or
>produce)
>a technical document that, in full detail, describes the mechanisms *used* by
>setupto
Phillip J. Eby wrote:
> I was surprised that MAL didn't comment *then*, actually, and mistakenly
> thought it meant that our last discussion on the distutils-sig (and my
> attempts to deal with the problems) had been successful. Between that and
> MvL's mild response to the explicit discussion of
Neal Norwitz wrote:
> I was also working under the assumption that people would complain if
> they didn't like something. What do people think should happen for
> the "Possible features" section? Should I ask if there are any
> objections to each item?
some discussion on python-dev for each non
At 08:11 AM 4/19/2006 +0200, Giovanni Bajo wrote:
>Then, about new commands. Why should I need to do "import distutils2" to do,
>eg, "setup.py develop"? This doesn't break backward compatibility.
The develop command uses the egg_info command. egg_info uses the
setuptools enhanced MANIFEST scheme
Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> If so, can't we have some kind of versioning
>> system?
>
> We do: "import setuptools". We could perhaps rename it to "import
> distutils2" if you prefer, but it would mean essentially the same
> thing. :)
I believe the naming is important, though.
At 10:14 PM 4/18/2006 -0700, Neal Norwitz wrote:
>On 4/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
> > >who decided that setuptools should be added to 2.5, btw?
> >
> > Guido proposed it on Python-dev when the 2.5 schedule was first being
>
On 4/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
> >who decided that setuptools should be added to 2.5, btw?
>
> Guido proposed it on Python-dev when the 2.5 schedule was first being
> discussed. I discussed it with him off-list, ...
I thou
At 02:12 AM 4/19/2006 +0200, Giovanni Bajo wrote:
>But, why can't setuptools be gradually merged into distutils, instead of being
>kept as a separate package? Let's take a real example: setuptools' sdist is
>much enhanced, has integration with CVS/SVN, uses MANIFEST in a way that it
>really works,
Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> > So, I'm not too pleased by insinuations that setuptools is
> anything other > than a Python community project.
>
> I've no doubt about that at all, FWIW. I think you've put a lot of
> effort into discussing it with the community, and applaud you
At 07:08 PM 4/18/2006 -0400, Fred L. Drake, Jr. wrote:
>Saw that; hopefully I'll have a chance to look at it soon. I wonder,
>generally, if it should be merged into the distutils documentation. Those
>documents happen to be distutils-centric now, because that's what's been
>provided. Their title
At 12:49 AM 4/19/2006 +0200, Martin v. Löwis wrote:
>Fredrik Lundh wrote:
> > it's still listed under "possible additions" in the release PEP, and
> there don't
> > seem to be a PEP or any other easily located document that explains exactly
> > how it works, what's required from library developers
On Tuesday 18 April 2006 19:00, Phillip J. Eby wrote:
> He then mentioned it in his 2.5 slideshow at PyCon. This is the first
> anyone's objected to it, however, at least that I'm aware of.
Until the past week, I wasn't aware it was being considered. But then, I've
not been paying a lot of at
At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
>who decided that setuptools should be added to 2.5, btw?
Guido proposed it on Python-dev when the 2.5 schedule was first being
discussed. I discussed it with him off-list, to ensure that it could be
done in a way that wouldn't interfere with ex
Fredrik Lundh wrote:
> it's still listed under "possible additions" in the release PEP, and there
> don't
> seem to be a PEP or any other easily located document that explains exactly
> how it works, what's required from library developers, how it affects existing
> toolchains, etc. is this reall
Phillip J. Eby wrote:
> Your proposals, however, generally favor experts at the expense of the
> average user, and treat it as axiomatic that the benefits provided by
> setuptools are not worth having, no matter how small the cost.
mal's arguing from well-established Python design principles (imp
At 09:02 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
>Phillip J. Eby wrote:
> > At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
> >> Why should a 3rd party extension be hot-fixing the standard
> >> Python distribution ?
> >
> > Because setuptools installs things in zip files, and older versions of
>
Phillip J. Eby wrote:
> At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
>> Why should a 3rd party extension be hot-fixing the standard
>> Python distribution ?
>
> Because setuptools installs things in zip files, and older versions of
> pydoc don't work for packages zip files.
That doesn't ans
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
>Why should a 3rd party extension be hot-fixing the standard
>Python distribution ?
Because setuptools installs things in zip files, and older versions of
pydoc don't work for packages zip files.
>If you want to provide a hot fix for Python 2.3
Phillip J. Eby wrote:
> At 10:55 AM 4/18/2006 +0200, M.-A. Lemburg wrote:
>> Phillip.eby wrote:
>> > Author: phillip.eby
>> > Date: Tue Apr 18 02:59:55 2006
>> > New Revision: 45510
>> >
>> > Modified:
>> >python/trunk/Lib/pkgutil.py
>> >python/trunk/Lib/pydoc.py
>> > Log:
>> > Second phase
26 matches
Mail list logo
