"A.M. Kuchling" <[EMAIL PROTECTED]> writes:
> On Thu, Apr 20, 2006 at 07:53:55AM +0200, "Martin v. Löwis" quoted:
>> > It is flatly not possible to "fix" distutils and preserve backwards
>> > compatibility.
>
> Would it be possible to figure what parts are problematic, and
> introduce PendingDepr
Anthony> I don't think it's fair to say that Phillip just checked this
Anthony> in off on his own.
In addition, since he did the development in the Python sandbox, his
checkins all along have been there for everyone to see. It's not like he
did the work in Outer Mongolia then showed up o
On Thu, 2006-04-20 at 11:33 +0100, Guido van Rossum wrote:
> Unfortunately, this is mixed in with some stuff that isn't part of
> distutils' "core competency", like text utilities, process spawning,
> and option parsing. These should (eventually, when the 2.1
> compatibility requirement is lifted)
On Thu, 2006-04-20 at 07:53 +0200, "Martin v. Löwis" wrote:
> > 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
On Thu, Apr 20, 2006, A.M. Kuchling wrote:
>
> I don't mind rewriting much, but hate leaving the original code in
> place; this is confusing to new users, even if it's convenient for
> existing users. How many HTML parsers are in the core now? (My gut
> feeling is that that Python's adoption curv
On Thu, Apr 20, 2006 at 07:53:55AM +0200, "Martin v. Löwis" quoted:
> > It is flatly not possible to "fix" distutils and preserve backwards
> > compatibility.
Would it be possible to figure what parts are problematic, and
introduce PendingDeprecationWarnings or DeprecationWarnings so
that we can
Guido van Rossum wrote:
> I'd rather recommend the approach that Joel suggests for truly large
> systems: refactoring smaller components while keeping the overall
> structure intact.
That's fine as long as the overall structure isn't the
very thing that's wrong and needs to be fixed.
Incremental
On 4/20/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Anthony Baxter wrote:
>
> >>http://www.joelonsoftware.com/articles/fog69.html
>
> From what I remember, he didn't actually say that you
> should never rewrite anything, but that if you do, you
> need to be prepared for a very long period
Anthony Baxter wrote:
>>http://www.joelonsoftware.com/articles/fog69.html
From what I remember, he didn't actually say that you
should never rewrite anything, but that if you do, you
need to be prepared for a very long period of time
when nothing new is working, and that *if you are a
co
Greg Ewing wrote:
> Fredrik Lundh wrote:
>
> > (distutils and setuptools are over 15000 lines of code, according to sloc-
> > count.
>
> Ye cats! That's a *seriously* big ball of mud. I just checked,
> and the whole of Pyrex is only 17000 lines.
correction: it's actually only 14000 lines, but it'
Phillip J. Eby wrote:
> If they have Pyrex installed, setuptools uses
> Pyrex to rebuild the .c from the .pyx.
I hope it would only do this if the .pyx was newer than the
.c. It's probably not a good idea to assume that just because
Pyrex is around, the user wants to use it in all cases. He
migh
Fredrik Lundh wrote:
> (distutils and setuptools are over 15000 lines of code, according to sloc-
> count.
Ye cats! That's a *seriously* big ball of mud. I just checked,
and the whole of Pyrex is only 17000 lines.
--
Greg
___
Python-Dev mailing list
Py
Phillip J. Eby wrote:
> 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 th
Greg Ewing wrote:
> I'm not sure whether distutils is really that
> badly broken. But an earlier poster seemed to be
> saying that he had great difficulty finding anything
> that could be changed without breaking something
> that someone relied on. It's hard to fix something
> if you can't change i
On Thursday 20 April 2006 15:53, Martin v. Löwis wrote:
> I don't know about Phillip's plans, but I do see many indications
> that people stop using distutils, and use setuptools instead.
Surely that's an indication that it _should_ become part of Python? If
there's an obvious demand for the feat
On 4/19/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> I see a significant procedural difference between what happened
> for ctypes, elementtree, and pysqlite, as opposed to setuptools.
> For all these packages, there was
> 1. a desire of users to include it
> 2. an indication from the packag
On Thursday 20 April 2006 15:54, Martin v. Löwis wrote:
> If you (Anthony) want to act as a second for setuptools, I
> would feel much happier - because I can then blame you for
> whatever problems that decision causes five years from now.
Done. See my longer reply "setuptools in 2.5". I think I j
Anthony Baxter wrote:
> I'm not sure how people would prefer this be handled. I don't think we
> need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
> pysqlite or cProfile, either.
I see a significant procedural difference between what happened
for ctypes, elementtree, and pys
Anthony Baxter wrote:
> And I would reply that sometimes a rewrite is necessary. I doubt
> firefox would be at the state it is today if it was still based on
> the ancient netscape codebase.
It's off-topic here certainly: but firefox is actually not a complete
rewrite; it still has tons of "anc
Anthony Baxter wrote:
>> It is *precisely* my concern that this happens. For whatever
>> reason, writing packaging-and-deployment software is totally
>> unsexy. This is why setuptools is a one-man show, and this is why
>> the original distutils authors ran away after they convinced
>> everybody tha
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
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
>
At 10:39 AM 4/20/2006 +1000, Anthony Baxter wrote:
>On Thursday 20 April 2006 03:46, Martin v. Löwis wrote:
> > It is *precisely* my concern that this happens. For whatever
> > reason, writing packaging-and-deployment software is totally
> > unsexy. This is why setuptools is a one-man show, and thi
On Thursday 20 April 2006 06:08, [EMAIL PROTECTED] wrote:
> Fredrik> for some reason, tools of this kind tend to reach the
> big ball Fredrik> of mud stage even before they reach the dogfood
> stage. and Fredrik> once you have a big ball of mud, you simply
> won't get much Fredrik> outside hel
Martin v. Löwis wrote:
> If distutils is now abandoned and replaced with
> something else, the same story will happen again: the developers will
> run away, the package gets abandoned,
Seems to me that if we had something with a clean
design that was easy to understand, maintain and
extend, that
On Thursday 20 April 2006 03:46, Martin v. Löwis wrote:
> It is *precisely* my concern that this happens. For whatever
> reason, writing packaging-and-deployment software is totally
> unsexy. This is why setuptools is a one-man show, and this is why
> the original distutils authors ran away after t
At 04:15 PM 4/19/2006 -0400, A.M. Kuchling wrote:
>At least some of these changes to Distutils seem unobjectionable for
>inclusion.
>
>For example, the changes to Command just allow keyword arguments on
>two methods and adds a class attribute; they seem unlikely to break
>any existing users of the
On Wed, Apr 19, 2006 at 03:02:15PM -0400, Phillip J. Eby wrote:
> I can tell you the reasons, no need to guess:
5. The Distutils has lots of customization hooks, but if the exact
hook you need isn't there, you're in deep trouble. I learned this
when trying to implement a package database.
> I a
Fredrik> for some reason, tools of this kind tend to reach the big ball
Fredrik> of mud stage even before they reach the dogfood stage. and
Fredrik> once you have a big ball of mud, you simply won't get much
Fredrik> outside help
Not to mention many dogs won't eat mud...
Skip
__
Martin v. Löwis wrote:
> It is *precisely* my concern that this happens. For whatever reason,
> writing packaging-and-deployment software is totally unsexy.
for some reason, tools of this kind tend to reach the big ball of mud stage
even before they reach the dogfood stage. and once you have a b
At 07:46 PM 4/19/2006 +0200, Martin v. Löwis wrote:
>Greg Ewing wrote:
> >> I started refactoring some of the ugliness out of the internals of
> >> distutils last year, but was completely stymied by the demand that no
> >> existing setup.py scripts be broken.
> >
> > Instead of trying to fix distut
Greg Ewing wrote:
>> I started refactoring some of the ugliness out of the internals of
>> distutils last year, but was completely stymied by the demand that no
>> existing setup.py scripts be broken.
>
> Instead of trying to fix distutils, maybe it would be better
> to start afresh with a new p
Gerhard Häring wrote:
> Speaking of which, what about SVN commit privileges for me?
Send me your key, and I'll add you. I assume 'gerhard.haering'
would work as the commit name?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
On Wed, 2006-04-19 at 18:26 +1200, Greg Ewing wrote:
> I'd like to see a different approach taken to the design
> altogether, something more along the lines of Scons.
> Maybe it could even be an extension of Scons.
As much as I like Scons, there's too much unpythonic magic going on
there that I w
On Wed, 2006-04-19 at 02:06 -0400, Phillip J. Eby wrote:
> >
> >I agree. My one stupid nit is that I don't like the name
> >'easy_install'. I wish a better, non-underscored word could be found.
>
> The long term plan is for a tool called "nest" to be offered, which will
> offer a command-line i
On Wed, Apr 19, 2006 at 10:54:09AM +0200, Gerhard Häring wrote:
> We should probably check my docs in soon even in a preliminary state, so
> they can be reviewed/improved.
There's a group of volunteers who will help fix the LaTeX markup, so
you certainly don't need to have everything working (or
On Tue, Apr 18, 2006 at 09:10:20PM -0700, Neal Norwitz wrote:
> There is an outstanding issues section in the 2.5 release PEP 356. In
> this case, perhaps it would have been good to add a bullet item there.
> I've been trying to ensure the issues aren't lost. There's only one
> item in the list t
Phillip J. Eby wrote:
> At 09:11 AM 4/19/2006 +0200, Walter Dörwald wrote:
>> With setuptools this doesn't work, because the package is distributed
>> over multiple egg-directories. AFAICR setuptools has a solution for
>> this, but only if the package __init__.py is empty (because setuptools
>> ge
Neal Norwitz wrote:
> On 4/18/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> On Wed, 2006-04-19 at 14:57 +1000, Anthony Baxter wrote:
>>> I'm not sure how people would prefer this be handled. I don't think we
>>> need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
>>> pysqlite or
Neal Norwitz wrote:
> What are the doc plans for these modules:
> + * ctypes
> + * ElementTree/cElementTree
> + * msilib
> + * pysqlite
pysqlite: I've started on new module docs for the "sqlite3" module in
the Python standard library, based on the text from the existing
pysql
At 09:11 AM 4/19/2006 +0200, Walter Dörwald wrote:
> With setuptools this doesn't work, because the package is distributed
> over multiple egg-directories. AFAICR setuptools has a solution for this,
> but only if the package __init__.py is empty (because setuptools
> generates it). But I'd like
At 09:08 AM 4/19/2006 +0200, Fredrik Lundh wrote:
>I've skimmed
>the PEAK documentation, and all I find is bullet-point feature lists and
>endless lists of configuration options. It's like reading Microsoft
>documentation.
And I've read your email about the documentation, and all I find is
hyper
At 08:51 AM 4/19/2006 +0200, Fredrik Lundh wrote:
>do you expect linux and bsd packagers to switch to your stuff for all their
>python needs,
Heck no, which is why setuptools tries hard to be compatible with bdist_*
commands. As long as they use --root or
--single-version-externally-managed, se
Anthony Baxter wrote:
> On Wednesday 19 April 2006 16:22, Walter Dörwald wrote:
>> If I'm not calling shared libraries from Python I can ignore
>> ctypes. If I'm not doing XML, I can ignore elementtree. If I'm not
>> doing SQL I can ignore pysqlite and if I'm not interested in
>> profiling I can ig
Anthony Baxter wrote:
> I'm not sure how people would prefer this be handled. I don't think we
> need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
> pysqlite or cProfile, either.
That's because they're all trivial building blocks, not all-consuming world
views. Any programmer
Phillip J. Eby wrote:
> 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.
yum already
At 08:22 AM 4/19/2006 +0200, Walter Dörwald wrote:
>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.
>
>If I'm not calling shared libraries f
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 setuptool
Anthony Baxter 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 packa
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.
If I'm not calling shared libraries from Python I can ignore ctypes. If
I'm not doing XML, I c
At 01:33 AM 4/19/2006 -0400, Barry Warsaw 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.
>
>Agreed
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.
>
> C
At 02:57 PM 4/19/2006 +1000, Anthony Baxter wrote:
>Sure, it's possible that some people with extremely complicated
>distutils scripts may find they need to update them.
...if and *only* if they want setuptools' features, or their users do.
Sorry to seize on this point out of context, Anthony. I
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.
Agreed. If modules like these have a solid history of use ou
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 don't have a problem at all with setuptools going into the standard
library. It adds a whole pile of extremely useful fun
On 4/18/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> > As for discussion, Guido originally brought up the question here a few
> > months ago, and it's been listed in PEP 356 for a while. I've also
> > posted things related to the inclusion both here and in distutils-sig.
56 matches
Mail list logo
