Thanks for posting an excellent summary, Anthony.
For the record, I'm taking full responsibility for the decision that
setuptools is going in. Having read much (though not all) of the
endless bitching, and the responses from Phillip and others in
defense, I still believe it's the right decision. I
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
On Thursday 20 April 2006 16:30, Martin v. Löwis wrote:
> I think it is unfair (to Richard Jones) to attribute this to
> setuptools. We already have a CPAN-type system: the Cheeseshop.
> What setuptools adds is roughly the CPAN shell (ie. CPAN.pm
> or however it is implemented). Actually, I think i
Greg Ewing wrote:
> I'm not sure whether distutils is really that
> badly broken. But an earlier poster seemed to be
> saying that he had great difficulty finding anything
> that could be changed without breaking something
> that someone relied on. It's hard to fix something
> if you can't change i
Anthony Baxter wrote:
> And now let's look at some of the stuff that setuptools gives us:
>
> - We have a CPAN-type system
I think it is unfair (to Richard Jones) to attribute this to
setuptools. We already have a CPAN-type system: the Cheeseshop.
What setuptools adds is roughly the CPAN shell (
On Thursday 20 April 2006 15:53, Martin v. Löwis wrote:
> I don't know about Phillip's plans, but I do see many indications
> that people stop using distutils, and use setuptools instead.
Surely that's an indication that it _should_ become part of Python? If
there's an obvious demand for the feat
On 4/19/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> I see a significant procedural difference between what happened
> for ctypes, elementtree, and pysqlite, as opposed to setuptools.
> For all these packages, there was
> 1. a desire of users to include it
> 2. an indication from the packag
On Thursday 20 April 2006 15:54, Martin v. Löwis wrote:
> If you (Anthony) want to act as a second for setuptools, I
> would feel much happier - because I can then blame you for
> whatever problems that decision causes five years from now.
Done. See my longer reply "setuptools in 2.5". I think I j
Anthony Baxter wrote:
> I'm not sure how people would prefer this be handled. I don't think we
> need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
> pysqlite or cProfile, either.
I see a significant procedural difference between what happened
for ctypes, elementtree, and pys
Anthony Baxter wrote:
> And I would reply that sometimes a rewrite is necessary. I doubt
> firefox would be at the state it is today if it was still based on
> the ancient netscape codebase.
It's off-topic here certainly: but firefox is actually not a complete
rewrite; it still has tons of "anc
Anthony Baxter wrote:
>> It is *precisely* my concern that this happens. For whatever
>> reason, writing packaging-and-deployment software is totally
>> unsexy. This is why setuptools is a one-man show, and this is why
>> the original distutils authors ran away after they convinced
>> everybody tha
Anthony Baxter wrote:
> - Multiple installs of different versions of the same package,
> including per-user installs.
yeah, but where is the documentation on how this works ? phillip points
to a 30-page API description, which says absolutely nothing whatsoever
about the files I'm going to find o
In an attempt to help this thread reach some sort of resolution,
here's a collection of arguments against and in favour of setuptools
in 2.5. My conclusions are at the end.
The arguments against:
- Someone should instead just fix distutils.
Right. And the amount of yelling if distutils ch
On Thursday 20 April 2006 14:18, Fredrik Lundh wrote:
> Anthony Baxter wrote:
> > > http://www.joelonsoftware.com/articles/fog69.html
> >
> > Yes. I remember that piece. In particular, he wrote the original
> > rant about this about Mozilla/Firefox. How did that work out
> > again? Oh, that
At 10:08 PM 4/19/2006 -0500, Michael Urman wrote:
>On 4/19/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > People blame setuptools when pydoc doesn't work on packages in zip
> > files. Rather than refer to some theoretical argument why it's not my
> > fault and I shouldn't be the one to fix it,
Anthony Baxter wrote:
> > http://www.joelonsoftware.com/articles/fog69.html
>
> Yes. I remember that piece. In particular, he wrote the original rant
> about this about Mozilla/Firefox. How did that work out again? Oh,
> that's right - we now have a much, much more successful and usable
>
On 4/19/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> People blame setuptools when pydoc doesn't work on packages in zip
> files. Rather than refer to some theoretical argument why it's not my
> fault and I shouldn't be the one to fix it, I prefer to fix the problem.
So rather than extract the
On 4/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> No, it wouldn't. There's no problem in giving an operator
> different unary and binary meanings; '-' already does
> that.
However unlike -, there is a two character ** operator, so while x--y
is the same as x - - y, x**y would not be the same as
At 10:39 AM 4/20/2006 +1000, Anthony Baxter wrote:
>On Thursday 20 April 2006 03:46, Martin v. Löwis wrote:
> > It is *precisely* my concern that this happens. For whatever
> > reason, writing packaging-and-deployment software is totally
> > unsexy. This is why setuptools is a one-man show, and thi
On Thursday 20 April 2006 06:08, [EMAIL PROTECTED] wrote:
> Fredrik> for some reason, tools of this kind tend to reach the
> big ball Fredrik> of mud stage even before they reach the dogfood
> stage. and Fredrik> once you have a big ball of mud, you simply
> won't get much Fredrik> outside hel
Martin v. Löwis wrote:
> If distutils is now abandoned and replaced with
> something else, the same story will happen again: the developers will
> run away, the package gets abandoned,
Seems to me that if we had something with a clean
design that was easy to understand, maintain and
extend, that
On Thursday 20 April 2006 03:46, Martin v. Löwis wrote:
> It is *precisely* my concern that this happens. For whatever
> reason, writing packaging-and-deployment software is totally
> unsexy. This is why setuptools is a one-man show, and this is why
> the original distutils authors ran away after t
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> FWIW: The docs are currently in the README file in Tools/pybench.
I took a look. The only thing that puzzles me is 'warp factor', which
appears exactly once.
tjr
___
Py
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
On Apr 19, 2006, at 3:19 PM, Phillip J. Eby wrote:
> At 08:45 PM 4/19/2006 +0200, M.-A. Lemburg wrote:
>> Phillip J. Eby wrote:
>>> 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 ex
At 04:15 PM 4/19/2006 -0400, A.M. Kuchling wrote:
>At least some of these changes to Distutils seem unobjectionable for
>inclusion.
>
>For example, the changes to Command just allow keyword arguments on
>two methods and adds a class attribute; they seem unlikely to break
>any existing users of the
On Wed, Apr 19, 2006 at 03:02:15PM -0400, Phillip J. Eby wrote:
> I can tell you the reasons, no need to guess:
5. The Distutils has lots of customization hooks, but if the exact
hook you need isn't there, you're in deep trouble. I learned this
when trying to implement a package database.
> I a
Fredrik> for some reason, tools of this kind tend to reach the big ball
Fredrik> of mud stage even before they reach the dogfood stage. and
Fredrik> once you have a big ball of mud, you simply won't get much
Fredrik> outside help
Not to mention many dogs won't eat mud...
Skip
__
Martin v. Löwis wrote:
> It is *precisely* my concern that this happens. For whatever reason,
> writing packaging-and-deployment software is totally unsexy.
for some reason, tools of this kind tend to reach the big ball of mud stage
even before they reach the dogfood stage. and once you have a b
At 08:45 PM 4/19/2006 +0200, M.-A. Lemburg wrote:
>Phillip J. Eby wrote:
> > 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 distribu
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
At 07:46 PM 4/19/2006 +0200, Martin v. Löwis wrote:
>Greg Ewing wrote:
> >> I started refactoring some of the ugliness out of the internals of
> >> distutils last year, but was completely stymied by the demand that no
> >> existing setup.py scripts be broken.
> >
> > Instead of trying to fix distut
overriding __getattr__ and __setattr__ has several negative side effects, for example:* inside__getattr__/__setattr__ you have to use self.__dict__["attr"] instead of
self.attr* it's easy to get stack overflow exceptions when you do something wrong
* you must remember to call the super's [get/set]
[removing the python-checkins CC]
Phillip J. Eby wrote:
> 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 setupto
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
>
Greg Ewing wrote:
>> I started refactoring some of the ugliness out of the internals of
>> distutils last year, but was completely stymied by the demand that no
>> existing setup.py scripts be broken.
>
> Instead of trying to fix distutils, maybe it would be better
> to start afresh with a new p
Gerhard Häring wrote:
> Speaking of which, what about SVN commit privileges for me?
Send me your key, and I'll add you. I assume 'gerhard.haering'
would work as the commit name?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>> Tim Peters wrote:
>>> [M.-A. Lemburg]
I could contribute pybench to the Tools/ directory if that
makes a difference:
>>> +1. It's frequently used and nice work. Besides, then we could
>>> easily fiddle the tests to make Python look better ;
On Wed, 2006-04-19 at 18:26 +1200, Greg Ewing wrote:
> I'd like to see a different approach taken to the design
> altogether, something more along the lines of Scons.
> Maybe it could even be an extension of Scons.
As much as I like Scons, there's too much unpythonic magic going on
there that I w
On Wed, 2006-04-19 at 02:06 -0400, Phillip J. Eby wrote:
> >
> >I agree. My one stupid nit is that I don't like the name
> >'easy_install'. I wish a better, non-underscored word could be found.
>
> The long term plan is for a tool called "nest" to be offered, which will
> offer a command-line i
At 11:41 PM 4/19/2006 +1000, Nick Coghlan wrote:
>Given that naming though, I think contextlib.contextmanager should be renamed
>to contextlib.context.
The name is actually correct under this terminology
arrangement. @contextmanager *returns* a context manager. It happens to
also be a context,
At 11:10 PM 4/19/2006 +1000, Nick Coghlan wrote:
>Ah, all is explained by svn blame, with a little help from svn log.
>
>When Phillip went through to make the terminology consistent he actually
>swapped the meanings of "context" (which meant 'has a __context__ method' in
>the original PEP)
At leas
A.M. Kuchling wrote:
> On Wed, Apr 19, 2006 at 11:10:55PM +1000, Nick Coghlan wrote:
>> When Phillip went through to make the terminology consistent he actually
>> swapped the meanings of "context" (which meant 'has a __context__ method'
>> in the original PEP) and "context manager" (which meant
On Wed, Apr 19, 2006 at 11:10:55PM +1000, Nick Coghlan wrote:
> When Phillip went through to make the terminology consistent he actually
> swapped the meanings of "context" (which meant 'has a __context__ method'
> in the original PEP) and "context manager" (which meant 'has __enter__ and
> __ex
Nick Coghlan wrote:
> The second occurrence of "context manager" is meant to say "context":
>
> This PEP proposes that the protocol used by the with statement be
> known as the "context management protocol", and that objects that
> implement that protocol be known as "context manage
On Wed, Apr 19, 2006 at 10:00:21PM +1000, Nick Coghlan wrote:
> And the parenthetical comment was completely backwards and should have read:
>
> (This means that all context managers are contexts, but not all contexts
> are
>context managers).
>
> The reason for recommending that context
On Wed, Apr 19, 2006 at 10:54:09AM +0200, Gerhard Häring wrote:
> We should probably check my docs in soon even in a preliminary state, so
> they can be reviewed/improved.
There's a group of volunteers who will help fix the LaTeX markup, so
you certainly don't need to have everything working (or
On Tue, Apr 18, 2006 at 09:10:20PM -0700, Neal Norwitz wrote:
> There is an outstanding issues section in the 2.5 release PEP 356. In
> this case, perhaps it would have been good to add a bullet item there.
> I've been trying to ensure the issues aren't lost. There's only one
> item in the list t
A.M. Kuchling wrote:
> On Tue, Apr 18, 2006 at 03:37:37PM -0400, Phillip J. Eby wrote:
>> I was going to say, "so they can be context managers", but I suppose you
>> have a point. There is no need for a context to have a __context__ method,
>> unless it is also a context manager. Ugh.
>
> It w
Phillip J. Eby wrote:
> At 09:11 AM 4/19/2006 +0200, Walter Dörwald wrote:
>> With setuptools this doesn't work, because the package is distributed
>> over multiple egg-directories. AFAICR setuptools has a solution for
>> this, but only if the package __init__.py is empty (because setuptools
>> ge
Giovanni Bajo:> Both ctypes and construct provide a way to describe a> binary-packed structure in Python terms: and this is an overload of> functionalityso does struct, so why not just use struct? there's a receipe at the python
cookbook that adds "naming ability" to fields, i.e.">6s.destincation
M.-A. Lemburg wrote:
> Tim Peters wrote:
>> [M.-A. Lemburg]
>>> I could contribute pybench to the Tools/ directory if that
>>> makes a difference:
>> +1. It's frequently used and nice work. Besides, then we could
>> easily fiddle the tests to make Python look better ;-)
>
> That's a good argumen
Neal Norwitz wrote:
> On 4/18/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> On Wed, 2006-04-19 at 14:57 +1000, Anthony Baxter wrote:
>>> I'm not sure how people would prefer this be handled. I don't think we
>>> need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
>>> pysqlite or
Neal Norwitz wrote:
> What are the doc plans for these modules:
> + * ctypes
> + * ElementTree/cElementTree
> + * msilib
> + * pysqlite
pysqlite: I've started on new module docs for the "sqlite3" module in
the Python standard library, based on the text from the existing
pysql
At 09:11 AM 4/19/2006 +0200, Walter Dörwald wrote:
> With setuptools this doesn't work, because the package is distributed
> over multiple egg-directories. AFAICR setuptools has a solution for this,
> but only if the package __init__.py is empty (because setuptools
> generates it). But I'd like
At 09:08 AM 4/19/2006 +0200, Fredrik Lundh wrote:
>I've skimmed
>the PEAK documentation, and all I find is bullet-point feature lists and
>endless lists of configuration options. It's like reading Microsoft
>documentation.
And I've read your email about the documentation, and all I find is
hyper
At 08:51 AM 4/19/2006 +0200, Fredrik Lundh wrote:
>do you expect linux and bsd packagers to switch to your stuff for all their
>python needs,
Heck no, which is why setuptools tries hard to be compatible with bdist_*
commands. As long as they use --root or
--single-version-externally-managed, se
Anthony Baxter wrote:
> On Wednesday 19 April 2006 16:22, Walter Dörwald wrote:
>> If I'm not calling shared libraries from Python I can ignore
>> ctypes. If I'm not doing XML, I can ignore elementtree. If I'm not
>> doing SQL I can ignore pysqlite and if I'm not interested in
>> profiling I can ig
Anthony Baxter wrote:
> I'm not sure how people would prefer this be handled. I don't think we
> need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
> pysqlite or cProfile, either.
That's because they're all trivial building blocks, not all-consuming world
views. Any programmer
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
61 matches
Mail list logo
