Re: [Python-Dev] setuptools in the stdlib ( r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)

[Phillip J. Eby]

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
>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 in-
>spect) the data, etc, setuptools should *not* go into 2.5.

And that is a mostly-specific, very fair, and completely reasonable 
objection.  And I think a significant portion of it is answered by the 
existing documentation, at least with respect to the runtime.  The 
pkg_resources API module includes all of the discovery, dependency 
resolution and introspection other facilities used by setuptools, and it 
does not depend on the rest of setuptools, which is directed primarily at 
building and installing eggs.  A number of users have written simple Python 
scripts using the documented API in order to list installed packages and 
that sort of thing.  The current API reference documentation is available 
at http://peak.telecommunity.com/DevCenter/PkgResources .)

I do think that "changes the structure of an installed Python system" is 
rather vague, though.  Python supports .pth files, for example, so is 
writing to a .pth file "changing the structure of an installed Python 
system"?  Python supports installing modules in directories on PYTHONPATH 
or specifying zip files on it, so are these operations "changing structure"?

I ask not to argue, but to make sure I know what else it is that you want 
documented, so I can be specific about what is and isn't documented.  My 
vague guess at the moment is that the only things that setuptools does 
which could be considered "changing the structure of an installed Python 
system" are:

1. If installing to a PYTHONPATH directory (instead of site-packages), it 
adds a special 'site.py' file so that .pth files are processed in 
PYTHONPATH directories.  (Python does not normally process .pth files on 
PYTHONPATH, but this is necessary to support dynamic installation of 
packages without modifying PYTHONPATH itself.  'site' is hooked instead of 
'sitecustomize' to avoid interfering with a user-defined 'sitecustomize'.)

2. If installing a package in "compatibility mode" (aka 
--single-version-externally-managed, or if --root was specified), it adds 
an .egg-info directory to hold setuptools-specific metadata.  This will be 
named something like 'FooBar-1.0.egg-info', and placed in the target 
directory alongside the installed package.  So if the package were 
installed as Lib/foobar, the egg-info would be stored in 
Lib/FooBar-1.0.egg-info/.

___
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] Raising objections (was: setuptools in the stdlib)

[Fredrik Lundh]

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 who's ever used a C compiler/linker, xml loader,
or embedded database will understand how to use them, and what they
do, right from the start.  There's not a trace of "you don't need to under-
stand this" or "won't anybody think of the newbies!" in any of them.

They're also all relatively close to the simplest thing that could possibly
work.

setuptools, in contrast, appears to be an overengineered kitchen sink
with tons of magic in-phillips-head-only features, all of which may have
unforseen effects on all parts of your Python installation.  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.





___
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] Raising objections

[Walter Dörwald]

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 ignore cProfile. But setuptools will potentially
>> affect anyone that uses third-party modules/packages.
> 
> Sure. It might mean people can automatically install something like 
> TurboGears and all it's dependencies, without stuffing their existing 
> required versions (thanks to eggs) and without having to fetch 16 
> different packages. Oh, the horror! 

I'm not saying that setuptools doesn't fix a real problem. It does! I'm 
just saying that for something that might have this far reaching 
consequences, the "why" and "how" should be documented somewhere. And 
this "somewhere" shouldn't be the depths of the distutils-SIG archives.

>> And ctypes, elementtree and pysqlite are mature packages.
>> setuptools isn't even finished yet.
> 
> Neither is distutils. setuptools at least is likely to be "finished", 
> whatever that means.
> 
>> Wouldn't I need at least have to change "from distutils.core import
>> setup" to "from setuptools import setup"? Or to something like:
> 
> Nope, only if you want to use the new, nicer functionality. If you 
> want to stick with the status quo, you're quite welcome to.

After two failed attempts to use setuptools for my own projects, I'd 
still like to use it, but this seems difficult (maybe this has changed 
since then, so correct me if I'm wrong): I'd like to distribute my 
modules as modules inside the top-level ll package. With distutils I can 
put the package __init__.py into either a separate distributing archive 
or into the core distribution archive and ignore the warning given by 
setup.py for the other packages. 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 to put at least 
a useful docstring into this __init__.py.

Servus,
Walter

___
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] Raising objections (was: setuptools in the stdlib)

[Phillip J. Eby]

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, setuptools should play nice with them.


>or are you building a parallel universe ?  if so, why ?

Many Python users are unable to use existing packaging systems - if for 
example they're not root, or their platform doesn't have one (Windows and Mac).

People developing Python applications often need to switch between 
different versions of Python packages, and manage what packages are 
distributed with their application, while sometimes using bleeding edge 
versions.  They can't use a system packaging tool either.

People distributing Python libraries don't want to have to build packages 
for each and every Linux flavor, plus BSDs and other platforms.

People creating extensible applications and frameworks (Zope, TurboGears, 
Chandler, Trac, ...) can't use system packagers to install and manage their 
plugins, or the libraries used by their plugins, especially if they're 
end-user applications or are run in shared hosting space.

And there are probably other reasons that are escaping me at the 
moment.  Mainly, though, setuptools offers developers relief from having to 
support myriad packaging systems in order to be able to depend on other 
Python packages.  They specify their dependencies in terms of PyPI, not in 
terms of distribution X's name for a system package that installs that 
facility.  That and plugin support are setuptools' core raison d'etre.

___
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] Raising objections (was: setuptools in the stdlib)

[Phillip J. Eby]

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 
hyperbole, whining, and a total absence of any specific criticism that 
could be used to *improve* the documentation.  It's like reading an effbot 
rant.  :)

Perhaps you would care to at least share *which* piece of documentation you 
are referring to, perhaps by URL, since your description does not sound 
like any of the three setuptools-related manuals to me.  (Unless of course 
you didn't bother to scroll past the table of contents or to click on any 
of those underlined "bullet points" in the tables of contents to go to the 
sections offering an explanation of the features in question.)

___
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] Raising objections

[Phillip J. Eby]

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 to put at least a useful docstring into this 
> __init__.py.

Actually, I believe that recent versions of setuptools actually do support 
your use case.  In fact, I seem to recall having emailed you once I got it 
to work with your scenario, and you told me you'd already decided not to 
use it.  But it's late at night now and I'm tired and should stop answering 
these emails for now anyway.

___
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] Raising objections

[Gerhard Häring]

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 
pysqlite reference manual. Progress is about 5 % perhaps, I spent the 
most time figuring out how the Python doc build process works.

We should probably check my docs in soon even in a preliminary state, so 
  they can be reviewed/improved.

Speaking of which, what about SVN commit privileges for me?

It's not a big problem to tunnel my stuff through Anthony or others, but 
   I think this would save resources.

-- Gerhard
___
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] Raising objections

[Thomas Heller]

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 cProfile, either.
>> Correct
>> me if I'm wrong, but I don't think any of the above are currently
>> documented in the stdlib.
> 
> Ok, I will. :-)  cProfile is documented in libprofile.tex.
> 
> None of the others are documented, also msilib doesn't appear to have
> any doc.  I've updated the PEP to mention these issues.  Thanks for
> pointing it out!
> 
> Note that there is probably a bunch of doc, but it all needs to be
> incorporated into the python repo and format.
> 
> What are the doc plans for these modules:
> +  * ctypes
> +  * ElementTree/cElementTree
> +  * msilib
> +  * pysqlite
> 
> n
I'm now happy with the tool that converts the ctypes tutorial from reST to 
LaTeX,
I will later (today or tomorrow) commit that into Python SVN.

Thomas

___
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] 2.5a1 Performance

[M.-A. Lemburg]

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 argument :-)
> 
> Note that the tests are versioned and the tools refuses to
> compare tests with different version numbers.

If there are no objections, I'll do some pybench cleanup today and
check it in.

Regarding the procedure, I think I have to import it under external/
first and then copy it over to Tools/. Is that correct ?

I'll also have to add some documentation. Question is: where ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 19 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] adding Construct to the standard library?

[tomer filiba]

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 6s.source H.type"something like that, so when you parse you get named attributes instead ofa tuple. so why did ctypes wrote another mechanism? because you can't extend 
it and you can't nest it. but ctypes, just as well, provides the mechanisms for its requirements -- defining C structs, not arbitrarily complex structures. so of courseit doesnt, and shouldnt, support variable-length fields or data pointers, which are 
common  in file formats, protocols, and other complex data structures -- whatyou can't do with a C struct you don't need to do with ctypes.now i'll save me a mail and put this also here:
Greg Ewing:> It does seem rather silly to have about 3 or 4> different incompatible ways to do almost exactly> the same thing (struct, ctypes, NumPy and now> Construct).* struct is designed for packing and unpacking, but is very limited
* ctypes is not oriented at packing/unpacking, it only provided amechanism to handle its requirements, which are domain specificand not general purpose.* i never checked how NumPy packs arrays, etc., but it's also 
domain-specific, as it's a math library, not a generic packer/unpacker.and trust me those are not the only ones. the reason people have to *reinvent the wheel* every time is the lack of a *generic* parsing/building
library. (i prefer the term parsing over unpacking. check my blog for moredetails)yes, putting bytes together isn't too complicated, and because peopledon't have a built-in mechanism for that, they tend to just "oh, well,
it can't be too complicated, i'll just write one for me", and this yields manyflavors of packers/unpackers, all incompatible.Construct is the first library, that i'm aware of, that is dedicated to
parsing/building, instead of doing it as a side-kick domain-specificmechanism.Construct is a *superset* of all those packers and unpackers, andhad it been part of stdlib, people would have used it instead.
of course it's only been released a month ago, and couldnt have been already included in the stdlib, i still think it has a room there. existing projects can be ported without too much effort, and new ones could 
benefit from it as well.-tomerOn 4/19/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
tomer filiba <[EMAIL PROTECTED]> wrote:
> the point is -- ctypes can define C types. not the TCP/IP stack.> Construct can do both. it's a superset of ctype's typing mechanism.> but of course both have the right to *coexist* --> ctypes is oriented at interop with dlls, and provides the mechanisms
> needed for that.> Construst is about data structures of all sorts and kinds.>> ctypes is a very helpful library as a builtin, and so is Construct.> the two don't compete on a spot in the stdlib.
I don't agree. Both ctypes and construct provide a way to describe abinary-packed structure in Python terms: and this is an overload offunctionality. When I first saw Construct, the thing that crossed my head was:
"hey, yet another syntax to describe a binary-packed structure in Python".ctypes uses its description to interoperate with native libraries, whileConstruct uses its to interoperate with binary protocols. I didn't see a good
reason why you shouldn't extend ctypes so to provide features that it iscurrently missing. It looks like it could be easily extended to do so.Giovanni Bajo
___
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] Raising objections

[Walter Dörwald]

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
>> generates it). But I'd like to put at least a useful docstring into
>> this __init__.py.
> 
> Actually, I believe that recent versions of setuptools actually do
> support your use case.

Yes (except for the "docstring in __init__.py" bit).

> In fact, I seem to recall having emailed you
> once I got it to work with your scenario, and you told me you'd already
> decided not to use it.

Yes, however I'm still thinking about changing my package structure to
be able to use setuptools.

> But it's late at night now and I'm tired and
> should stop answering these emails for now anyway.

Servus,
   Walter
___
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] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

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 would be easy to just remove the parenthetical comment from the PEP
> and forget about it, if in fact the statement is now purposeless.  But
> these are murky waters, and maybe there's still some deeper reason for
> it.  Nick, do you have any comments?

Aside from wondering "Did I even pretend to proofread that paragraph?"?

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 managers". The term
 "context" then encompasses all objects with a __context__()
 method that returns a context object.

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 managers should be contexts is 
similar to the reason that iterators should be iterables - so that doing the 
__context__() call manually will still give you something that can be used in 
a with statement.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] Raising objections (was: setuptools in the stdlib)

[A.M. Kuchling]

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 that still needs addressing...

I've added another one: getting the SoC-funded new mailbox code into
the stdlib.  I trust someone will push back if they think that's a bad
idea.

--amk


___
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] Raising objections

[A.M. Kuchling]

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 even learn
much LaTeX) before the docs get committed.

--amk
___
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] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[A.M. Kuchling]

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 managers should be contexts is 
> similar to the reason that iterators should be iterables - so that doing 
> the __context__() call manually will still give you something that can be 
> used in a with statement.

So the intention is to enable something like:

ctx = lock.__context__()
with ctx:
...

Which works as long as people don't try to use the context in two
nested 'with' statements.  Fair enough.  I don't think I'll suggest
doing this in the "What's New", though.  :)

--amk
___
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] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

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 managers". The term
>  "context" then encompasses all objects with a __context__()
>  method that returns a context object.
> 
> 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 managers should be contexts is 
> similar to the reason that iterators should be iterables - so that doing the 
> __context__() call manually will still give you something that can be used in 
> a with statement.

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) and "context manager" (which meant 'has __enter__ and 
__exit__ methods and a __context__ method that returns self' in the original 
PEP).

I clearly wasn't paying attention when that diff went past on the checkins 
list, but I'd humbly request that we change it back :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[A.M. Kuchling]

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 
> __exit__ methods and a __context__ method that returns self' in the 
> original PEP).

Yes, that was exactly what he set out to do.  I noted that the terms
"context" and "context manager" seemed to be exactly reversed from
what's intuitive, and from how the user-facing documentation is
written; the post at

contains my argument.  GvR approved, and Phillip went ahead and made
the change.

--amk
___
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] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

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 'has __enter__ and 
>> __exit__ methods and a __context__ method that returns self' in the 
>> original PEP).
> 
> Yes, that was exactly what he set out to do.  I noted that the terms
> "context" and "context manager" seemed to be exactly reversed from
> what's intuitive, and from how the user-facing documentation is
> written; the post at
> 
> contains my argument.  GvR approved, and Phillip went ahead and made
> the change.

I'm a little behind on python-dev *and* python-checkins, so I'd missed the 
first half of this discussion.

It'll take me a while to swap the two in my head, but I'll get used to it 
eventually. Phillip's point that calling __context__ should give you a context 
as the result is a good one, and "context manager" makes sense as "an object 
that can generate new contexts".

Given that naming though, I think contextlib.contextmanager should be renamed 
to contextlib.context. The current name was assigned when objects with all 3 
methods were the one's being called "context managers". With the terms being 
swapped, the name of the decorator should probably change, too. Chopping 7 
characters off the name doesn't hurt, either :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

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 least AMK and I thought that it was obvious that "context manager" means 
"has a context method", and it's the only way to have the PEP read 
consistently.

Note that the decorator is called @contextmanager, not @context, for example.


>  and "context manager" (which meant 'has __enter__ and
>__exit__ methods and a __context__ method that returns self' in the 
>original PEP).

That's true - *before* there was a __context__ method.  Now that there *is* 
a context method, it makes more sense to say that the thing that has it is 
the context manager, and the thing with the __enter__/__exit__ methods is 
the context.


>I clearly wasn't paying attention when that diff went past on the checkins
>list, but I'd humbly request that we change it back :)

The change made the PEP self-consistent in its terminology, if you are 
encountering it for the first time, and don't already have it in your head 
that it's one way or the other.  If we change it the other way, we'll have 
to rename @contextmanager.

___
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] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

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, but that's not important.  "With" takes a context 
manager expression.

___
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] Raising objections (was: setuptools in the stdlib)

[Barry Warsaw]

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 interface similar to that of the "yum" package 
> manager, with commands to list, uninstall, upgrade, and perform other 
> management functions on installed packages.  It's not likely to be 
> available in time for the Python 2.5, release, but when it *is* available 
> you'll just "python -m easy_install --upgrade setuptools" to get it.  :)

Cool.  Sticking with the metaphor, where's the 'hatch' command and what
would it do? :)

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] Raising objections (was: setuptools in the stdlib)

[Barry Warsaw]

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 wouldn't want emulated.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] 2.5a1 Performance

[M.-A. Lemburg]

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 ;-)
>> That's a good argument :-)
>>
>> Note that the tests are versioned and the tools refuses to
>> compare tests with different version numbers.
> 
> If there are no objections, I'll do some pybench cleanup today and
> check it in.
> 
> Regarding the procedure, I think I have to import it under external/
> first and then copy it over to Tools/. Is that correct ?

It's in svn now and only an update away.

> I'll also have to add some documentation. Question is: where ?

FWIW: The docs are currently in the README file in Tools/pybench.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 19 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Raising objections

[Martin v. Löwis]

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://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Raising objections

[Martin v. Löwis]

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 package and a new name, then
> there wouldn't be any backwards-compatibility issues to
> hold it back.

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 that distutils should
be part of Python. 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, and, after a few years of sadness,
a new, smart developer will come along and provide a super replacement.
And that will repeat in cycles of roughly 10 years.

We have to stop this. If distutils has flaws, fix them. Never ever
even think about rewriting software:

http://www.joelonsoftware.com/articles/fog69.html

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] setuptools in the stdlib ([Python-checkins] r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)

[Ronald Oussoren]

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
> that it still allows distutils extensions like py2exe to work.  The  
> only
> real alternative to monkeypatching that I'm aware of for that issue  
> is to
> actually merge setuptools with the distutils, but my guess is that  
> you'll
> like that even less.  :)

Have you considered such a merger? It's rather odd to include a  
package in
the stdlib that monkeypatches another part of the stdlib.

For the record: I like setuptools and eggs.

Ronald
___
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] 3rd party extensions hot-fixing the stdlib (setuptools in the stdlib)

[M.-A. Lemburg]

[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 setuptools installs things in zip files, and older versions of
>>> pydoc don't work for packages zip files.
>> That doesn't answer my question.
> 
> That is the answer to the question you asked: "why hot-fix?"  Because 
> setuptools uses zip files, and older pydocs crash when trying to display 
> the documentation for a package (not module; modules were fine) that is in 
> a zip file.

I fail to see the relationship between setuptools and pydoc.

Please don't follow this route - you are putting the integrity
of the Python stdlib at risk.

The setuptools distribution is not the authoritative source for
these kinds of fixes and that should be made clear by separating
those parts out into a different package and making the
installation an explicit user option.

You should also note that users won't benefit from bug fixed
versions of e.g. such modules in patch level releases.

>> Third-party extensions *should not do this* !
> 
> If you install setuptools, you presumably would like for things to work, 
> and the hot fix eliminates a bug that interferes with them working.
> 
> I'm not sure, however, what you believe any of that has to do with 
> python-checkins or python-dev.  The version of setuptools that will do this 
> is not yet released, and the hotfix aspect will be documented.  If it 
> causes actual problems for actual setuptools users, it will be actually 
> fixed or actually removed.  :)  (Meanwhile, the separately-distributed 
> setuptools package is not a part of Python, any more than the Optik is, 
> despite Python including the 'optparse' package spun off from Optik.)

It's an issue to discuss on python-dev because it touches
things that python-dev folks develop.

However, it's not related to the rest of this discussion,
so I'm changing the subject line and will respond to the rest
in a separate email.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 19 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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

[Python-Dev] bug with __dict__?

[tomer filiba]

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]attr or the MRO is broken* when deriving from a class that overrides one of the speical methods, you usuallyneed to override the special function of your class as well, to allow some "local storage"
for yourselfso i had an idea -- why not just replace __dict__? this does not affect the MRO. i wrote an AttrDict class, which is like dict, only it allows you to acces its keys as attributes. i later 
saw something like this on the python cookbook as well.
class AttrDict(dict):    def __init__(self, *a, **k):    dict.__init__(self, *a, **k)    self.__dict__ = selfthis code basically causes __getattr/setattr__ to use __getitem/setitem__:

a =AttrDict()a["blah"] = 5a.yadda = 6print a.blahprint a["yadda"]which is exactly what i wanted. now, i thought, instead of overriding __getattr/setattr__, i'd just write a class that overrides __getitem/setitem__. for example:
# old wayclass A(object):    def __getattr__(self, name):    return 5a = A()print a.xyz # 5# new wayclass mydict(dict):    def __getitem__(self, key):    return 5

class A(object):    def __init__(self):    self.__dict__ = mydict()a = A()print a.xyz # should print 5but lo and behold, python does not call my overriden method. it just bypasses it and always
calls the original dict's method. i made several tests, trying to see if it calls __contains__,placed hooks on __getattribute__, but nothing from *my* overriden methods is ever called. this is probably because the C implementation calls PyDict_GetItem or whatever directly... 
i think it's a bug. i should be able to override the __getitem__ of my __dict__. it breaks the polymorphism of python-level objects! on the one hand, i'm allowed to change __dict__ to anyobject that derives from dict, but i'm not allowed to override it's methods! 
python must either disable assigning to __dict__, or be willing to call overriden methods, notsilently ignore mine.-tomer


___
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] Raising objections

[Phillip J. Eby]

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 distutils, maybe it would be better
> > to start afresh with a new package and a new name, then
> > there wouldn't be any backwards-compatibility issues to
> > hold it back.
>
>It is *precisely* my concern that this happens. For whatever reason,
>writing packaging-and-deployment software is totally unsexy.

I can tell you the reasons, no need to guess:

1. It's bloody hard work.  Honestly, if I really knew what I was in for by 
doing this, I might not have started.  That doesn't mean I'm going to 
*stop*, just that I'd have thought twice before starting.

2. Everybody thinks they can do it better, and isn't afraid to tell you so.

3. People complain that things didn't magically work the way they expected, 
but rarely provide any information about what they did or didn't do or how 
they think it should've figured out what they mean.

4. When it works, nobody notices or cares.  When it doesn't work *once*, 
people blog that it's crap and should never be used -- but don't report the 
problem or ask for help, and don't change their judgment of "crap" even if 
the problem is fixed in a few days through somebody sending me mail about 
the blog article.


>  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, and, after a few years of sadness,
>a new, smart developer will come along and provide a super replacement.
>And that will repeat in cycles of roughly 10 years.
>
>We have to stop this. If distutils has flaws, fix them.

I agree with you, which is why setuptools fixes distutils' flaws by 
subclassing where possible and monkeypatching only where necessary to 
ensure compatibility.  (Only three classes are monkeypatched: Distribution, 
Command, and Extension.)

It would be better to simply integrate those changes into the distutils in 
the long run, rather than maintaining two layers.  The problem in the short 
term, however, is backward compatibility: sometimes people are relying on 
internals or implementation details of the existing distutils.

I would suggest that setuptools be considered "distutils2" for all 
practical purposes, with the intention of being merged into the distutils 
proper for Py3K.  Whether setuptools gets included in Python 2.5 or not, it 
should be in *some* 2.x release, and merge fully in 3.x.

___
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] setuptools in the stdlib ([Python-checkins] r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)

[Phillip J. Eby]

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 enhanced alternative.

Also, there are two practical issues:

1. How to activate or deactivate backward compatibility for packages or 
people relying on intimate details of current distutils behaviors

2. Maintaining the existing version of setuptools to work with Python 2.3 
and 2.4, which would not have this integration with the distutils.

___
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] 3rd party extensions hot-fixing the stdlib (setuptools in the stdlib)

[Phillip J. Eby]

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 distribution ?
> >>> Because setuptools installs things in zip files, and older versions of
> >>> pydoc don't work for packages zip files.
> >> That doesn't answer my question.
> >
> > That is the answer to the question you asked: "why hot-fix?"  Because
> > setuptools uses zip files, and older pydocs crash when trying to display
> > the documentation for a package (not module; modules were fine) that is in
> > a zip file.
>
>I fail to see the relationship between setuptools and pydoc.

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.


>The setuptools distribution is not the authoritative source for
>these kinds of fixes and that should be made clear by separating
>those parts out into a different package and making the
>installation an explicit user option.

...which nobody will use, following which they will still blame setuptools 
for pydoc's failure.

But I do agree that it might be a good idea to:

1) tell people about the issue
2) tell people that the fix is being installed
3) make it easy to remove the fix

However, maybe I should just create 'pydoc-hotfix' and 'doctest-hotfix' 
packages on PyPI and then tell people to "easy_install pydoc-hotfix 
doctest-hotfix".  Or perhaps just create a "pep302-hotfixes" package that 
includes all of the PEP 302 support changes for linecache, traceback, and 
so on, although I'm not sure how many of those can be installed in such a 
way that the fixes would be active prior to the stdlib versions being imported.

I suppose I could handle the "nobody will use it" problem by having 
easy_install nag about the hotfixes not being installed when running under 
2.3 or 2.4.


>You should also note that users won't benefit from bug fixed
>versions of e.g. such modules in patch level releases.

The pydoc fixes to support zip files are too extensive to justify 
backporting, as they rely on features provided elsewhere.  So if bug fixes 
occur on the 2.5 trunk, I would have to update the hotfix versions directly.

___
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] Raising objections

[Fredrik Lundh]

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 big ball
of mud, you simply won't get much outside help -- not because it's unsexy,
but because it's nearly impossible to contribute, at any level, unless you
have days and days to spare...

(distutils and setuptools are over 15000 lines of code, according to sloc-
count.  it took Python several years to accumulate a standard library that
big ;-)





___
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] Raising objections

[skip]

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
___
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] Raising objections

[A.M. Kuchling]

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 agree with you, which is why setuptools fixes distutils' flaws by 
> subclassing where possible and monkeypatching only where necessary to 
> ensure compatibility.  (Only three classes are monkeypatched: Distribution, 
> Command, and Extension.)

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 class.

The Extension change replaces .pyx source files with .c; I'm not sure
what the purpose of this change is, but it clearly might cause
problems for distributions with Pyrex source files.

The Distribution changes add some more optional kw arguments -- no
problem there -- and a bunch of egg-specific methods.  This set would
need some further study, and also bakes in .egg support; we'd have to
be very sure that .eggs are the way to go, so this might need a PEP
and/or BDFL pronouncement.

Obviously, applying changes to Distutils makes Phillip's maintenance
of setuptools more difficult -- now he has to worry about
monkeypatching or not depending on the Python version.  But at least
some of the monkeypatching can be removed -- maybe all of it if the
Distribution class proves amenable.

--amk
___
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] Raising objections

[Phillip J. Eby]

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 class.
>
>The Extension change replaces .pyx source files with .c; I'm not sure
>what the purpose of this change is, but it clearly might cause
>problems for distributions with Pyrex source files.

The purpose of the extension change is that it first checks whether Pyrex's 
distutils extension is available.  If it is not available, it changes the 
source file names to .c, so that any pre-processed Pyrex files will be 
processed.  This allows Pyrex-using packages to include pre-translations 
from Pyrex to C, and non-Pyrex users can still compile the package.

For example, PyProtocols ships with a _speedups.pyx file, and a _speedups.c 
file, produced locally with Pyrex.  Let's say a user is building 
PyProtocols from source.  If they have Pyrex installed, setuptools uses 
Pyrex to rebuild the .c from the .pyx.  If they do *not* have Pyrex 
installed, setuptools tells distutils to just build directly from the .c 
file, so that the distutils isn't confused by all this '.pyx' business.


>The Distribution changes add some more optional kw arguments -- no
>problem there -- and a bunch of egg-specific methods.  This set would
>need some further study, and also bakes in .egg support; we'd have to
>be very sure that .eggs are the way to go, so this might need a PEP
>and/or BDFL pronouncement.

There's a slightly deeper issue there than just egg support itself.  It's 
*plugin* support.  Setuptools allows eggs to register plugins to provide 
new commands or keyword options that then apply either globally or only to 
specific setup scripts.  Setuptools then uses this mechanism to register 
its own commands as distutils replacements.

What this means is that if setuptools is installed, and you use setuptools' 
Distribution class, then setuptools' command plugins will apply -- which 
means that you now have setuptools behavior for those commands, instead of 
distutils default behavior.  And this would be the case even if you never 
imported setuptools, if you just ported the Distribution class over.

So, you can't actually activate the plugin support in setuptools' 
Distribution for distutils, or you'll be removing backward 
compatibility.  There would have to be some way to specify whether 
setuptools or distutils should take precedence in the event that both 
define a given command.  For example, a 'use_setuptools' argument that 
defaults to false, unless you first imported setuptools (for back/side 
compatibility w/existing setuptools scripts).


>Obviously, applying changes to Distutils makes Phillip's maintenance
>of setuptools more difficult -- now he has to worry about
>monkeypatching or not depending on the Python version.

Yeah, there's already some of this to deal with for package 
data.  Setuptools was added to the sandbox in 2004, and shortly afterwards, 
Fred Drake took on the task of adding some of its features to distutils for 
Python 2.4.  Which was great, except that then setuptools had to start 
worrying about whether or not the stuff it was subclassing was in fact 
already doing what it was trying to do.  So, there's a bunch of fragile 
conditional code in there, and I'm not thrilled at the idea of adding more, 
because it significantly increases the number of testing combinations 
required to ensure that things work when changes are made, as well as 
making it harder to tell what's going on in the code.


>   But at least
>some of the monkeypatching can be removed -- maybe all of it if the
>Distribution class proves amenable.

The Distribution class also adds the ability for individual commands to 
have positional argument parsing.

___
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] 3rd party extensions hot-fixing the stdlib (setuptools in the stdlib)

[James Y Knight]

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 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 answer my question.
>>>
>>> That is the answer to the question you asked: "why hot-fix?"   
>>> Because
>>> setuptools uses zip files, and older pydocs crash when trying to  
>>> display
>>> the documentation for a package (not module; modules were fine)  
>>> that is in
>>> a zip file.
>>
>> I fail to see the relationship between setuptools and pydoc.
>
> 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.

FWIW, I see very little harm from setuptools replacing the old  
version of pydoc with a later official python version which causes it  
to actually work with setuptools.

Twisted has also done some of of this kind of thing in the past, so  
that the code can be written to use modules/features in current  
versions of python yet still run on earlier versions where that  
functionality doesn't exist/doesn't work. I don't recall ever hearing  
of a user complaining about said monkeypatching. Users want  
compatibility with older versions of python, and sometimes that may  
mean you have to patch said older version's stdlib to make it work.

James
___
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] setuptools in the stdlib ( r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)

[Fredrik Lundh]

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, setuptools should *not* go into 2.5.
>
> And that is a mostly-specific, very fair, and completely reasonable
> objection.  And I think a significant portion of it is answered by the
> existing documentation, at least with respect to the runtime.  The
> pkg_resources API module includes all of the discovery, dependency
> resolution and introspection other facilities used by setuptools, and it
> does not depend on the rest of setuptools, which is directed primarily at
> building and installing eggs.  A number of users have written simple Python
> scripts using the documented API in order to list installed packages and
> that sort of thing.  The current API reference documentation is available
> at http://peak.telecommunity.com/DevCenter/PkgResources .)

What I want is a PEP that explains the things that are manipulated by
this API.  What things are stored where, what do they contain, and how
are they are used by the various tools ?

The API in itself isn't very interesting; I'm interested in the underlying
design.





___
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] setuptools in the stdlib ( r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)

[Phillip J. Eby]

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 can manipulate (or at
> > > least inpect) the data, etc, setuptools should *not* go into 2.5.
> >
> > And that is a mostly-specific, very fair, and completely reasonable
> > objection.  And I think a significant portion of it is answered by the
> > existing documentation, at least with respect to the runtime.  The
> > pkg_resources API module includes all of the discovery, dependency
> > resolution and introspection other facilities used by setuptools, and it
> > does not depend on the rest of setuptools, which is directed primarily at
> > building and installing eggs.  A number of users have written simple Python
> > scripts using the documented API in order to list installed packages and
> > that sort of thing.  The current API reference documentation is available
> > at http://peak.telecommunity.com/DevCenter/PkgResources .)
>
>What I want is a PEP that explains the things that are manipulated by
>this API.  What things are stored where, what do they contain, and how
>are they are used by the various tools ?
>
>The API in itself isn't very interesting; I'm interested in the underlying
>design.

But the API *documentation* is where you'll find:

* The external formats understood for version numbers and version requirements
* The escaping and comparison rules for project names and version numbers
* The external formats used for dependency listings
* The external formats used for declaring plugins
* The conceptual overview for the design, including terminology and the 
design concepts exposed by the objects and operations
* A link to the original design overview, which I wrote with a mind to it 
becoming part of a PEP someday:

http://mail.python.org/pipermail/distutils-sig/2005-June/004652.html

And probably many more things that I don't recall off the top of my head.

If what you want is an implementer's guide to which actual files contain 
what data in which of the above formats, I'll admit there isn't such a 
roadmap.  I could probably write one up by tomorrow, since it would mostly 
be a list of "here are the filenames, this is what format in the existing 
documentation is used for this file, and here's what the contents are used 
for, and here are some pointers to relevant parts of the user and API docs 
that you should read in order to understand what this is for".

However, if you don't read at least the API docs, you're definitely going 
to be missing most of the design picture.

___
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] 2.5a1 Performance

[Terry Reedy]

"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



___
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] Raising objections

[Anthony Baxter]

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 they convinced
> everybody that distutils should be part of Python. If distutils is
> now abandoned and replaced with something else, the same story will
> happen again: the developers will run away, 

Well, I've seen no indication that this is Phillip's plan. If it is, 
could he tell us now?  

> the package gets 
> abandoned, and, after a few years of sadness, a new, smart
> developer will come along and provide a super replacement. And that
> will repeat in cycles of roughly 10 years.

Well, I'm planning on trying to get across the setuptools codebase 
before 2.5 final. 

> We have to stop this. If distutils has flaws, fix them. Never ever
> even think about rewriting software:

I started looking at this. The number of complaints I got when I 
started on this that it would break the existing distutils based 
installers totally discouraged me. In addition, the existing 
distutils codebase is ... not good. 

It is flatly not possible to "fix" distutils and preserve backwards 
compatibility. Sometimes you _have_ to rewrite. I point to 
urllib->urllib2, asyncore->twisted, rfc822/mimelib/&c->email. 
This approach means that people's existing code continues to work, 
there's a separate installer of the new code that is available for 
older versions of Python, plus we have the newer features. 

> 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 
browser. 

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] Raising objections

[Greg Ewing]

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 this wouldn't be so much of a problem.
If the original author ran away, others would more
easily be able to take over the task.

> We have to stop this. If distutils has flaws, fix them. Never ever
> even think about rewriting software:

Usually this is good advice, but it is possible
for something to be so badly broken that the only
reasonable way to fix it is to throw it away and
start over.

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 it at all.

I'd be happy to discuss ways of evolving distutils
into something better, but first we have to decide
that it is actually permissible to change it and
possibly break stuff that's relying on its internals.

--
Greg
___
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] Raising objections

[Anthony Baxter]

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 help
>
> Not to mention many dogs won't eat mud...

Most dogs will eat _anything_ that might look like food. 



___
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] Raising objections

[Phillip J. Eby]

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 this is why
> > the original distutils authors ran away after they convinced
> > everybody that distutils should be part of Python. If distutils is
> > now abandoned and replaced with something else, the same story will
> > happen again: the developers will run away,
>
>Well, I've seen no indication that this is Phillip's plan. If it is,
>could he tell us now? 

I don't know how widely the distutils were used *before* they became a part 
of Python, so it's possible the authors didn't know what they were in 
for.  Of course, it's still possible that I don't know what I'm in for 
either.  However, the amount of work I've been putting in wouldn't be 
possible without OSAF's indirect finanical support for the project.

But, setuptools solves problems that commercial entities are often 
interested in solving.  The Envisage folks inquired at Pycon about me 
possibly helping expand setuptools' scope to building and installing C 
dynamic link libraries, and this is also a feature potentially desired for 
Chandler's build system as well.

What this means is that there is a potential basis for supporting the work 
going forward, at least through what I'm hoping will be the "1.0" 
version.  And I suspect that there are other improvements possible that 
other commercial entities would be interested in funding.

How much any of that could have also applied to the distutils at one time, 
I don't know.  My point is merely that setuptools has enough commercial 
value to make me believe that sponsorship for features shouldn't be that 
hard to come by, and there are certainly worse things I could do with my 
work days.

This shouldn't be construed as saying I'll only work on setuptools if paid; 
it merely means that the huge gobs of time I've been putting into it at 
times are only *possible* because it aligns with OSAF goals enough to let 
me put a substantial chunk of my work days and nights into it.


>I started looking at this. The number of complaints I got when I
>started on this that it would break the existing distutils based
>installers totally discouraged me. In addition, the existing
>distutils codebase is ... not good.

You know, after my experience doing setuptools, I'm a lot less inclined to 
criticize anybody's code, if it works and solves a problem.  Sometimes, the 
structure of the problems are just not amenable to beautiful solutions.  Or 
more to the point, beautiful solutions are not always economical to 
implement while you're supporting actual users and backwards compatibility 
is a constant requirement.  So my attitude to the distutils code has 
mellowed considerably; I view it as a collection of things that I at least 
don't have to think about.  C compilers, for example, are something I don't 
have to touch at all, except for some recent experiments in implementing 
shared library building.

So, I don't really view the distutils as broken per se; it's just that they 
lack a lot of desirable features that are hard to implement without 
breaking backward compatibility.  That's not quite the same thing as "the 
code sucks and we should rewrite it".  There have been a lot of calls to 
scrap it and rewrite it throughout the years I've been working on 
setuptools, but I can't imagine who could possibly *afford* such an 
undertaking (as opposed to talking about it).


>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
>browser.

Well, the analogy isn't great anyway, because setuptools is hardly a 
rewrite of the distutils.  I didn't rewrite a single thing I could get away 
with calling or subclassing.  Setuptools is all about adding new features, 
not "cleaning up" the distutils code base, so arguing about whether 
rewrites are good or not is a straw man holding a red herring.  :)

___
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] a flattening operator?

[Michael Urman]

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 x * * y.

Michael
--
Michael Urman  http://www.tortall.net/mu/blog
___
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] 3rd party extensions hot-fixing the stdlib (setuptools in the stdlib)

[Michael Urman]

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 zip at install time (something purely
within setuptool's domain), you found modifying pydoc's behavior to be
a more compelling story. Are you aware that zipimport fails on 64-bit
systems in Python 2.3, or do you plan to patch over that as well?

Michael
--
Michael Urman  http://www.tortall.net/mu/blog
___
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] Raising objections

[Fredrik Lundh]

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
> browser.

his point isn't that it cannot be done, it's that it is horridly expensive
and time consuming.  exactly how much money and time has gone into
getting firefox to the point where it is today?

(insert obligatory bastiat reference here)





___
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] 3rd party extensions hot-fixing the stdlib (setuptools in the stdlib)

[Phillip J. Eby]

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, I prefer to fix the problem.
>
>So rather than extract the zip at install time (something purely
>within setuptool's domain), you found modifying pydoc's behavior to be
>a more compelling story.

Absolutely!  It adds a new and useful feature to Python, while extracting 
the files doesn't.  In the meantime, of course, I've told affected users to 
use the 'always-unzip' option when installing.


>  Are you aware that zipimport fails on 64-bit
>systems in Python 2.3, or do you plan to patch over that as well?

Nope.  I implemented a workaround instead.  :)  For a few months now, 
setuptools generates uncompressed zipfiles for Python 2.3, since it's only 
compressed zipfiles that give 64-bit zipimport fits.  The setuptools docs 
still claim you have to use Python 2.4 for 64-bit platforms, but I only 
left that in because there are still plenty of 2.3 compressed eggs floating 
around.

Do you know of any other Python bugs I should be fixing or working around?  :)

___
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] Raising objections

[Anthony Baxter]

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's right - we now have a much, much more
> > successful and usable browser.
>
> his point isn't that it cannot be done, it's that it is horridly
> expensive and time consuming.  exactly how much money and time has
> gone into getting firefox to the point where it is today?

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. 

In any case, this is not relevant, since setuptools is not a rewrite. 

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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

[Python-Dev] setuptools in 2.5.

[Anthony Baxter]

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 changed in a non-b/w 
compat way wouldn't be high. There's also the basic problem that the 
distutils code is _horrible_. 

 - It monkeypatches pydoc and distutils!

   It only monkeypatches pydoc when the separate setuptools installer 
is used on older Pythons. How is this relevant for this discussion of 
Python 2.5? The monkeypatching for distutils should be reduced - see 
AMK's message for a breakdown of this.

 - Documentation

   beaker% pydoc xmlcore.etree
   no Python documentation found for 'xmlcore.etree'

   beaker% pydoc ctypes
   no Python documentation found for 'ctypes'

   The documentation (of which there is plenty) can and will be folded 
into the standard python docs. Most of the new modules in 2.5 went in 
before their docs. 

 - Where's the PEP?

   I don't see the need. The stuff that could go into a PEP about 
formats and the like should go into the existing Distutils 
documentation. It's a far more useful place, and many more people are 
likely to find it there than in a PEP.

 - It's a huge amount of code (or "ball of mud"), or, it adds too many 
features.

   Most of these have been added over the last 2 years in response to 
feedback and requests from people on distutils-sig. There's been an 
obvious pent-up demand for a bunch of this work, and now that 
someone's working on it, these can get done.

 - It will break existing setup.py scripts!

   No it won't. If you don't type the letters 'import setuptools' into 
your setup.py, it won't be affected. 

 - Rewriting from scratch is bad

   This isn't a rewrite - it's built on top of distutils. 
(An aside, I don't buy the "never rewrite" argument. As I mentioned in 
an earlier message, look at urllib2, twisted and email for starters. 
In addition, look at Firefox, Windows XP, and Mac OSX. Hell, Linux 
could be considered a rewrite of Minix, once upon a time.)

 - Eggs are inferior to distribution-specific packaging

   Not all operating systems have a decent packaging system. The ones 
that do, don't support multiple versions of the same library. In 
addition, there's no reason why existing packaging systems can't just 
bundle up the code as they do now - if they also add a .egg-info file 
to the packages, that would be even better! Finally, these don't 
support user installation of software. This is particularly useful in 
a hosting environment. 


And now let's look at some of the stuff that setuptools gives us:

 - We have a CPAN-type system

   I do quite a number of Python talks, and this is _always_ one of 
the most requested features. There's been many attempts to write this, 
none have been completed until now. If you honestly don't see that 
this is a big thing for Python, then I am very, very suprised. I 
suspect that this will be the #1 new feature of Python 2.5 that the 
users will notice and be happy about.

 - Multiple installs of different versions of the same package, 
including per-user installs. 

   Again, as Python gets more widely used, this becomes a big issue.
Sure, it's not necessarily a killer argument for python-dev, but stuff 
that's added to Python shouldn't just be just for the use of 
python-dev. The multiple installed versions feature also avoids the 
CPAN dependency hell problem - back when I used to work with Perl, 
this was a constant source of nightmarish problems. 

 - The "develop" mode

   This makes life that bit less painful all-round. 

 - The plugin/extension support

   Extending distutils currently is a total pain in the arse. 

 - Backwards compatibility

   easy_install even works with existing packages that use traditional 
distutils, so long as they're in the Cheeseshop. Damn, this is nice. 
If you don't want to do the work to change your installation code, 
don't bother - it will still be useful. 

The conclusions:

I'm a little suprised by the amount of fear and loathing this has 
generated. To me, there are such obvious benefits that I don't see 
why people are so vehemently against setuptools. I haven't seen any 
arguments that have convinced me that this isn't the right thing to 
do. Yes, there's still work to be done - but hell, we've only 
released the first alpha so far.

For inclusion in the standard library, the usual benchmark is that the 
code offers useful functionality, and that it be the "best of breed". 
setuptools clearly meets these two criteria. (Ok, it's really "only of 
breed", but that also makes it "best", by default ). It's also 
been under development for over 2 years - according to svn, 0.0.1 was 
checked into svn back in March 2004.

I'm also suprised by how much some people seem to think that the 
current state of distutils functionality is acceptable or desirable. 

Re: [Python-Dev] setuptools in 2.5.

[Fredrik Lundh]

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 on my machine after doing a setuptools-
based installation, how those files are used, and what I can do with them
myself.

maybe it's nice to have a big abstraction with a dozen classes and inter-
faces, but if not even the developer can describe the concrete things be-
neath the abstractions, something's not entirely right.  especially when the
developer don't even seem to understand why anyone would care, when
he's already written all the code.

:::

and yes, for the record, setuptools has already created one support mess
for me, where the "gotta protect the average users from how this really
works" approach resulted in many average users not being able to get
things to work at all, even after trying out a magic workaround that
someone provided (along the lines of "python -msomething --something
walla walla/" - note the trailing slash, will do something else without it).

and I wasn't even using setuptools myself.  not that the users cared
about that; setuptools told them that my stuff didn't work, and couldn't
be installed, so of course they contacted me.

:::

but if this is so obvious, maybe someone could whip up a brief overview
document, that support volunteers like myself can refer to when people
get stuck ?  (preferrably someone who isn't Phillip, to prove that some-
one else actually understands all the relevant details).  if not a PEP, at
least a FAQ entry ?

pointing people to a couple of hundred pages of API and option listings
won't really work.  and "look in the distutils archives" won't work either.





___
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] Raising objections

[Martin v. Löwis]

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 that distutils should be part of Python. If distutils is
>> now abandoned and replaced with something else, the same story will
>> happen again: the developers will run away, 
> 
> Well, I've seen no indication that this is Phillip's plan. If it is, 
> could he tell us now?  

I don't know about Phillip's plans, but I do see many indications
that people stop using distutils, and use setuptools instead.

People change their setup.py files to setuptools.setup instead
of distutils.setup, since the former provides the same things
to them, just better. So effectively, distutils disappears
except as an implementation detail of setuptools.

There is much talk about backwards compatibility: these package
are then, of course, not backwards compatible with earlier
Python versions anymore. No problem: just install setuptools
on these earlier versions. So distutils isn't just abandoned
for the future versions, but also for past versions.

> I started looking at this. The number of complaints I got when I 
> started on this that it would break the existing distutils based 
> installers totally discouraged me. 

I believe this is a myth. Some changes might cause breakage, yes,
but others wouldn't. For example, introducing additional parameters
to setup is just fine: existing packages won't break; new packages
using these parameters won't build on older Python releases, of
course.

> In addition, the existing distutils codebase is ... not good. 

Then it shouldn't have become part of Python in the first place.
Can you please elaborate what specific aspects of distutils
you dislike?

> It is flatly not possible to "fix" distutils and preserve backwards 
> compatibility.

Why?

> Sometimes you _have_ to rewrite. I point to 
> urllib->urllib2, asyncore->twisted, rfc822/mimelib/&c->email. 

If I had the time, I would question each of these. Yes, it is
easier for the author of the new package to build "in the
green", but it is (nearly) never necessary, and almost always
bad for the project.

> This approach means that people's existing code continues to work, 
> there's a separate installer of the new code that is available for 
> older versions of Python, plus we have the newer features. 

Yes, and everybody has to rewrite their code, because the "old"
modules don't see fixes, and get obsoleted and eventually removed.
Users get the impression that Python breaks their APIs for no good
reason every now and then.

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] Raising objections

[Martin v. Löwis]

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 "ancient netscape codebase" in it.
The could not have completed it otherwise.

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] Raising objections

[Martin v. Löwis]

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 pysqlite, as opposed to setuptools.
For all these packages, there was
1. a desire of users to include it
2. an indication from the package maintainer that it's ok
   to include the package, and that he is willing to maintain it
3. some discussion on python-dev, which resulted only in support
   and no objection
4. some (other) committer who "approved" incorporation of the
   library. In essence, that committer is a "second" for the
   package inclusion.

setuptools has 1 and 2, but fails on 3 and 4 so far. There is
discussion now after the fact, but it results in objection.

I'd like to point out the importance of 4: Fredrik Lundh originally
asked "who approved that change", which really meant "who can I
blame for it". I feel that I approved inclusion of ctypes and
elementtree: I talked with the developers on how precisely it
should happen, and I checked then that everything that I thought
should happened indeed happened. And I did the majority of the
communication on python-dev. So the package authors can
get all the praise, and I happily take all the blame.

The same didn't happen for setuptools: there is no second,
so Phillip Eby takes all the praise *and* the blame. It's
still a one-man show.

Now, I know that Neal Norwitz had asked him what the status
is and when it will happen, but he apparently did not want
to *approve* inclusion of that package. Likewise, Guido
van Rossum (apparently) did not want to approve it, either
(he just would not object).

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.

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] Raising objections

[Anthony Baxter]

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 just did 
that. I'm happy to share any blame, but leave the credit to Phillip.

I don't think it's fair to say that Phillip just checked this in off 
on his own. 

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] Raising objections

[Neal Norwitz]

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 package maintainer that it's ok
>to include the package, and that he is willing to maintain it
> 3. some discussion on python-dev, which resulted only in support
>and no objection
> 4. some (other) committer who "approved" incorporation of the
>library. In essence, that committer is a "second" for the
>package inclusion.
>
> setuptools has 1 and 2, but fails on 3 and 4 so far. There is
> discussion now after the fact, but it results in objection.
>
> Now, I know that Neal Norwitz had asked him what the status
> is and when it will happen, but he apparently did not want
> to *approve* inclusion of that package. Likewise, Guido
> van Rossum (apparently) did not want to approve it, either
> (he just would not object).

I think Guido was more enthusiastic about it going in.  I want the
functionality, though have concerns about it.  These concerns are
based on my ignorance, I have never used setuptools nor looked at the
code.  I had these reservations for each of the packages we imported.

I plan to review the setuptools code.  Yes, I know it's 7k+ lines of
code.  It's near the top of my TODO list.  Summer of Code is the only
thing higher and that should not require too much time moving forward.

I will at least be familiar with the code.  I think if people have
specific concerns about the code, they should address them rather than
generalities.  I hope Phillip has or can easily write some doc that
will address the high-level or a roadmap.  I don't particularly care,
but others do.  I think it's reasonable to have and should be
relatively short (1-2 pages max IMO).

As for #3, there was some discussion and there was a chance for
objections, it just wasn't explicit.  So mistakes were made.  I will
try to ensure these issues are raised going forward and this problem
doesn't recur.  It's water under the bridge at this point.  I suspect
setuptools is the best we've got and the best we're gonna get.  It's
good enough to move forward.  While it may be a pain for some of us in
the short term, many users have asked for this for many years.  Let's
make it work.

n
___
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] Raising objections

[Anthony Baxter]

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 features.

In addition, it's available for 2.3 and 2.4 as a separate package.

> > I started looking at this. The number of complaints I got when I
> > started on this that it would break the existing distutils based
> > installers totally discouraged me.
>
> I believe this is a myth. Some changes might cause breakage, yes,
> but others wouldn't. For example, introducing additional parameters
> to setup is just fine: existing packages won't break; new packages
> using these parameters won't build on older Python releases, of
> course.

Something as simple as replacing the distutils.fancy_getopt with 
optparse couldn't be done in a completely backwards compatible way, 
because of some of the funkiness in fancy_getopt that people use 
today. 

> > In addition, the existing distutils codebase is ... not good.
>
> Then it shouldn't have become part of Python in the first place.
> Can you please elaborate what specific aspects of distutils
> you dislike?

It's extremely awkward to plug in functionality that _should_ be more 
obvious and extensible. At least, unless you want to make every 
single setup.py include a magic bit of patching to Do The Right 
Thing. 

There are a number of places where the code is obviously not finished, 
when Greg clearly got fed up with the project . There was no 
decent documentation of the internals. 

> > It is flatly not possible to "fix" distutils and preserve
> > backwards compatibility.
>
> Why?

Because there are too many people that have poked too deeply into the 
innards with their setup.py scripts. Partly this is a function of the 
lack of documentation - until I sat down and spent a couple of days 
on it a year or so ago, there wasn't a library reference. There's 
still no decent "here's the Approved Way to poke about inside 
distutils" doc. 

> If I had the time, I would question each of these. Yes, it is
> easier for the author of the new package to build "in the
> green", but it is (nearly) never necessary, and almost always
> bad for the project.

I guess I disagree almost entirely. The new email package is vastly, 
vastly better than the old hodge-podge of stuff that was written back 
in python's Dark Ages. Trying to fix those would have been almost 
impossible. In addition, we'd be stuck with the need to maintain 
backwards compatibility. Something like spambayes or almost anything 
else handling modern email traffic would then not be possible in 
Python. 

> Yes, and everybody has to rewrite their code, because the "old"
> modules don't see fixes, and get obsoleted and eventually removed.
> Users get the impression that Python breaks their APIs for no good
> reason every now and then.

distutils doesn't _get_ fixes. Well, hardly any. Compare that to a 
'svn log' in sandbox/setuptools. I know I much prefer an actively 
maintained and developed codebase to some ancient but inert existing 
system. Heck, most of the recent work on distutils was an offshoot of 
setuptools.

As far as "breaks their APIs" - this is a pretty rare occurance, it 
might have happened half a dozen times so far. And the old module 
still keeps working fine. If there's bugs that someone logs, they 
will get addressed exactly the same as any other bug. I don't see 
people closing patches off as "that's an old module, I'm not going to 
apply it". It also takes _years_ for older modules to go through the 
process of deprecation, moving to lib-old, and final removal. I mean, 
heck, rfc822 still doesn't issue any deprecation warnings. I suspect 
C++ or Java change faster .

Anthony

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] setuptools in 2.5.

[Martin v. Löwis]

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 (ie. CPAN.pm
or however it is implemented). Actually, I think it is ez_setup
that provides (something like) the CPAN shell.

It is my understanding that setuptools itself has nothing
to do with a CPAN-like system, just as Makemakefile.pl has
nothing to do with CPAN.

>  - Multiple installs of different versions of the same package, 
> including per-user installs. 

I never had the need, but I trust others do.

>  - The "develop" mode
> 
>This makes life that bit less painful all-round. 

This could be added to distutils with no problems, right?

>  - The plugin/extension support
> 
>Extending distutils currently is a total pain in the arse. 

If that's a desirable feature to have, it *should* be added
to distutils; IOW, it should be available if you do "from
distutils import setup", not just when you do "from setuptools
import setup".

> I'm a little suprised by the amount of fear and loathing this has 
> generated. To me, there are such obvious benefits that I don't see 
> why people are so vehemently against setuptools. I haven't seen any 
> arguments that have convinced me that this isn't the right thing to 
> do. Yes, there's still work to be done - but hell, we've only 
> released the first alpha so far.

I'm not looking at it from a end-user's point of view. I trust
that setuptools provides features that end-users want, and in
a convenient way. My fear is in the maintainer's side: how
many new bug reports will this add? How much code do I have to
digest to even make the slightest change?

That is says from itself that it is version 0.7a1dev-r45536
doesn't help to reduce that fear.

> I'm also suprised by how much some people seem to think that the 
> current state of distutils functionality is acceptable or desirable. 
> It's not - it's a mess. 

I would like to require that this is solved by contributing to
distutils, instead of replacing it. I know this is an unrealistic
request to make - in particular because there is only a single
developer world-wide which actively develops "something like that".

Requiring Phillip to rewrite distutils instead is certainly
unfair - but I'm still unhappy with the path events take.

> Finally, I'd like to point out that I think some of the hostility 
> towards Phillip's work has been excessive.

I'd like to make clear that my hostility is only towards his work;
never towards Phillip Eby himself.

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] Raising objections

[Martin v. Löwis]

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 it at all.

That's not been my experience with modifying distutils.
I fixed several bugs over the years, and always found
a way to fix them (or, rather, the contributor whose
patch I committed found a fix). OTOH, I never tried to
extend the architecture (but never had a need to, either).

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] setuptools in 2.5.

[Anthony Baxter]

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 it is ez_setup
> that provides (something like) the CPAN shell.

No, we have _half_ of a CPAN. We don't have the shell and the 
dependency finding and the ability to support multiple versions of 
the same package (at least, not without PYTHONPATH hell) and all the 
other stuff that makes CPAN useful.

And heck, Richard knows full well how good cheeseshop is. :-)

> It is my understanding that setuptools itself has nothing
> to do with a CPAN-like system, just as Makemakefile.pl has
> nothing to do with CPAN.

I'd disagree. A package index is a very nice and useful thing in and 
of itself. But it's only part of the solution.

> >  - The "develop" mode
> >
> >This makes life that bit less painful all-round.
>
> This could be added to distutils with no problems, right?

Not without a lot of the other stuff that's in setuptools. 

> That is says from itself that it is version 0.7a1dev-r45536
> doesn't help to reduce that fear.

It's had _two_ _years_ of quite active development, so the version 
number of 0.7 is hardly a good indication. As far as all the other 
stuff on the end of the version string - well, right now Python's SVN 
trunk really could be considered 2.5a2dev-r45575.

> I would like to require that this is solved by contributing to
> distutils, instead of replacing it. I know this is an unrealistic
> request to make - in particular because there is only a single
> developer world-wide which actively develops "something like that".
>
> Requiring Phillip to rewrite distutils instead is certainly
> unfair - but I'm still unhappy with the path events take.

He's written code on _top_ _of_ _distutils_. How is this bad? It's 
using the underlying existing code. 

> > Finally, I'd like to point out that I think some of the hostility
> > towards Phillip's work has been excessive.
>
> I'd like to make clear that my hostility is only towards his work;
> never towards Phillip Eby himself.

See, I don't get the hostility thing. While I have some concerns about 
the state of distutils today, I still admire Greg Ward's efforts in 
producing the code, and Python is in a much better place than had he 
not done the work. Responding to an effort like Greg's, or Phillip's, 
with hostility is a fantastic way to discourage people from working 
further on Python or on the code in question. 

Anthony


-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] setuptools in the stdlib ([Python-checkins] r45510 - python/trunk/Lib/pkgutil.py python/trunk/Lib/pydoc.py)

[Martin v. Löwis]

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
implementation details, because somebody might rely on them.

I firmly believe that this position is misguided, and that decisions
resulting from it should be corrected (over time, of course).
Beautiful is better than ugly: if you believe that the distutils
code is wrong in some respect, then change it.

Of course, things are more complicated in this approach: you have
to actively consider the likelyhood of breakage, and you have to
a) clearly document the potential for breakage: the more likely
   the breakage, the more visible the documentation should be
b) try to come up with recommendations for users should the
   any code actually break: users then want to know how they should
   change their code so that it works with previous versions of
   Python still.
c) ask for consent in advance to making a potentially-breaking
   change.

> 1. How to activate or deactivate backward compatibility for packages or 
> people relying on intimate details of current distutils behaviors

See above: on a case-by-case basis.

> 2. Maintaining the existing version of setuptools to work with Python 2.3 
> and 2.4, which would not have this integration with the distutils.

One way would be to make another distutils release, and require
setuptools users to install this distutils release as a prerequisite.

Another solution would be to fork setuptools, in a pre-2.5 branch and
a post-2.5 branch. Over time, the pre-2.5 branch could be abandoned.

A third solution likely exists on a case-by-case basis: conditionalize
code inside setuptools, depending on Python version (or other criteria).

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] setuptools in 2.5.

[Guido van Rossum]

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've learned my
lesson about discussing library additions early -- I didn't anticipate
any controversy on this one.

The way I see it is this: a distribution tool that handles
dependencies and other problems that distutils doesn't solve is sorely
needed; blessing a particular solution makes a huge difference in
acceptance, and acceptance is key for a distribution tool; setuptools
is pretty much the only available candidate (platform-specific tools
don't count).

So I'm blessing setuptools. I'm sure Phillip will fix the remaining
issues enumerated by Anthony below, and any new ones that might come
up during the release cycle. Please help by being constructive in your
criticism. Bug reports are useful. Whining is not.

--Guido

On 4/20/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> 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 changed in a non-b/w
> compat way wouldn't be high. There's also the basic problem that the
> distutils code is _horrible_.
>
>  - It monkeypatches pydoc and distutils!
>
>It only monkeypatches pydoc when the separate setuptools installer
> is used on older Pythons. How is this relevant for this discussion of
> Python 2.5? The monkeypatching for distutils should be reduced - see
> AMK's message for a breakdown of this.
>
>  - Documentation
>
>beaker% pydoc xmlcore.etree
>no Python documentation found for 'xmlcore.etree'
>
>beaker% pydoc ctypes
>no Python documentation found for 'ctypes'
>
>The documentation (of which there is plenty) can and will be folded
> into the standard python docs. Most of the new modules in 2.5 went in
> before their docs.
>
>  - Where's the PEP?
>
>I don't see the need. The stuff that could go into a PEP about
> formats and the like should go into the existing Distutils
> documentation. It's a far more useful place, and many more people are
> likely to find it there than in a PEP.
>
>  - It's a huge amount of code (or "ball of mud"), or, it adds too many
> features.
>
>Most of these have been added over the last 2 years in response to
> feedback and requests from people on distutils-sig. There's been an
> obvious pent-up demand for a bunch of this work, and now that
> someone's working on it, these can get done.
>
>  - It will break existing setup.py scripts!
>
>No it won't. If you don't type the letters 'import setuptools' into
> your setup.py, it won't be affected.
>
>  - Rewriting from scratch is bad
>
>This isn't a rewrite - it's built on top of distutils.
> (An aside, I don't buy the "never rewrite" argument. As I mentioned in
> an earlier message, look at urllib2, twisted and email for starters.
> In addition, look at Firefox, Windows XP, and Mac OSX. Hell, Linux
> could be considered a rewrite of Minix, once upon a time.)
>
>  - Eggs are inferior to distribution-specific packaging
>
>Not all operating systems have a decent packaging system. The ones
> that do, don't support multiple versions of the same library. In
> addition, there's no reason why existing packaging systems can't just
> bundle up the code as they do now - if they also add a .egg-info file
> to the packages, that would be even better! Finally, these don't
> support user installation of software. This is particularly useful in
> a hosting environment.
>
>
> And now let's look at some of the stuff that setuptools gives us:
>
>  - We have a CPAN-type system
>
>I do quite a number of Python talks, and this is _always_ one of
> the most requested features. There's been many attempts to write this,
> none have been completed until now. If you honestly don't see that
> this is a big thing for Python, then I am very, very suprised. I
> suspect that this will be the #1 new feature of Python 2.5 that the
> users will notice and be happy about.
>
>  - Multiple installs of different versions of the same package,
> including per-user installs.
>
>Again, as Python gets more widely used, this becomes a big issue.
> Sure, it's not necessarily a killer argument for python-dev, but stuff
> that's added to Python shouldn't just be just for the use of
> python-dev. The multiple installed versions feature also avoids the
> CPAN dependency hell problem - back when I used to work with Perl,
> this was a constant source of nightmarish problems.
>
>  - The "develop" mode
>
>This makes life that bit less painful all-round.
>
>  - The plugin/extension support
>
>Extending distutils currently is a total pa