Greg Ewing wrote:
> Ivan Krstić wrote:
>
>> That'd be nice. And on that note, for the love of confused masses
>> everywhere, can we please change the name of easy_install to something
>> Python-specific, such as 'egg' or 'py_install'?
>
> I don't think that easy_install support is going to
> beco
On Oct 15, 2006, at 12:59 AM, Greg Ewing wrote:
Ivan Krstić wrote:
That'd be nice. And on that note, for the love of confused masses
everywhere, can we please change the name of easy_install to
something
Python-specific, such as 'egg' or 'py_install'?
I don't think that easy_install supp
Phillip J. Eby wrote:
>>> This sounds good. We definitely need *something* with
>>> a more modular and better documented architecture than
>>> distutils.
>>
>> I definitely disagree. Why are you calling distutils non-modular?
>> It was designed to be modular and extensible,
>
> No, it's designed t
Phillip J. Eby schrieb:
> The difference between the two is that an extensible system is one that
> follows the same rules for extenders as it does for its core
> developers. For example, in the distutils, there are two ways to
> register commands: one for extenders, and one for core developers.
At 01:41 PM 10/15/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby schrieb:
> > The difference between the two is that an extensible system is one that
> > follows the same rules for extenders as it does for its core
> > developers. For example, in the distutils, there are two ways to
> > regist
Phillip J. Eby schrieb:
> Last, but not least, the distutils suffer from an excess of policy
> flexibility in areas where flexibility is undesirable from a community
> perspective. There should be "one obvious way" to do a lot of things
> that the distutils provide a ridiculous number of ways to d
At 06:58 PM 10/15/2006 +0200, Martin v. Löwis wrote:
>Phillip J. Eby schrieb:
> > Last, but not least, the distutils suffer from an excess of policy
> > flexibility in areas where flexibility is undesirable from a community
> > perspective. There should be "one obvious way" to do a lot of things
>
Martin v. Löwis wrote:
> It's only a terminology issue, but I think most people would assume
> a different definition for "extensible". I'd call a system extensible
> if it supports being extended, period.
What matters is how easily and in what ways it can be
extended. My experiences with attempt
Phillip J. Eby wrote:
> Meanwhile, the higher-level layer is based on the idea of dependency
> between sequentially invoked commands, rather than dependency between
> things being built.
This is what bothers me most about the design of distutils,
I think. A setup.py file should be structured lik
Ronald Oussoren wrote:
> Even then easy_install support won't be univeral. I still run into
> packages that don't use distutils, mostly stuff that is or was part of
> a larger C code base.
However, at least there would be One Obvious Way for
those that do want to use a standard build system.
Greg Ewing schrieb:
> 1. Pyrex: The distutils extension for compiling Pyrex
> modules (which was contributed, not written by me)
> seems to work by abusing an existing mechanism for
> dealing with swig files. That it was necessary to do
> this rather than just adding something new is not a
> good s
Greg Ewing schrieb:
> Which it *shouldn't* have to do. Timestamp checking
> is fundamental to any kind of build process. It
> should be built into the very foundations of the tool,
> not left for each extension to re-invent separately.
And indeed, distutils already has support for that:
distutils.
On Oct 16, 2006, at 6:48 AM, Martin v. Löwis wrote:
Greg Ewing schrieb:
Which it *shouldn't* have to do. Timestamp checking
is fundamental to any kind of build process. It
should be built into the very foundations of the tool,
not left for each extension to re-invent separately.
And indeed,
13 matches
Mail list logo
