[Python-3000] Proposal: No more standard library additions

["Martin v. Löwis"]

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 do (e.g.
> insane project directory layouts including package-by-package directory
> mapping).  This is not something that affects the distutils themselves
> much, but it essentially prevents the distutils from improving in
> certain ways because there are so few assumptions one can make about its
> use.

While each of these points might be true, I also believe they can
be fixed. For example, it would be possible to deprecate-then-remove
a non-standard package mapping. I'm not sure how many packages actually
use such a mapping, but we would learn about them through the
deprecation (or they just fix their package).

>> Actually, it is possible to add a new compiler to some Python
>> installation, so that users can pass it to the --compiler option,
>> and distutils packages don't have to be modified for that.
>> You just have to extend the dictionary
>> distutils.ccompiler.compiler_class.
> 
> Yes, and how do you accomplish *that*?  You have to either modify some
> Python code (e.g. sitecustomize) or use a big -c to python when running
> the setup script.

There is a third option: write a .pth file, and put that on the path.

> With entry point extension, it is only necessary to have an extension
> installed on sys.path; it is not necessary to run some code to do the
> registration.

One thing that bothers me about setuptools is the strange, non-intuitive
terminology. What is "entry point extension"? If you'd call it "ini
files listing command names", I could understand much better.

> Adding setuptools-style plugin ability to the distutils is very simple,
> and doesn't require a wholesale reorganization.  After all, setuptools
> manages to do it!

Ok, if that's the most desired property, I think it should be added
(provided somebody is willing to contribute, of course); one doesn't
have to wait for 3.0 to add it.

> However, there are areas of build functionality that
> the distutils does not cover or provides incomplete coverage for, such
> as configuration and build of more complex C libraries and programs,
> shared libraries, documentation production, and so on, that the existing
> architecture of the distutils doesn't really encompass.

I agree it doesn't cover it. I don't see why it isn't "easy" to add
it (where "easy" really means "as easy doing it stand-alone").

> Meanwhile, the higher-level layer is based on the idea of dependency
> between sequentially invoked commands, rather than dependency between
> things being built.  This makes it difficult to deal with concepts like
> having a bunch of reST release note docs combined with a LaTeX
> documentation build.

This I don't understand. Couldn't there be a subcommand of "build" that
creates the documentation? Of course, that command would have to do
the time-stamp checking, and use whatever build machinery is appropriate
(make, ant, scons, ...).

> So, distutils' extensibility *could* be improved dramatically in the 2.x
> line by adding setuptools-style plugin entry points.  However, adding
> any *new* build functionality to the distutils is probably going to be
> better off being based on something that offers an extensible
> object-dependency layer, ala zc.buildout.

I don't mind adding a time-stamp-or-content-based dependency
infrastructure to the standard library, either, and it might be useful
to reimplement the existing build commands on top of that
(for example, it bothers me that the standard setup.py doesn't take
 header file dependencies into account, for the modules of the standard
 library).
That's still no reason to drop distutils.

> (Which reminds me.  Does anybody have any idea why the distutils compile
> modules in build/?  There seems to be no point to this, since any
> installation of the modules is going to need to recompile them.  Even
> bdist operations end up recompiling them in a different location!)

It was added to build_py.py with this checkin:

r17820 | gward | 2000-10-02 04:19:04 +0200 (Mon, 02 Oct 2000) | 8 lines

Added the ability to do byte-compilation at build time, currently off
by default (since compiling at install time works just fine).  Details:
  - added 'compile' and 'optimize' options
  - added 'byte_compile()' method
  - changed 'get_outputs()' so it includes bytecode files
A lot of the code added is very similar to code in install_lib.py;
would be nice to factor it out further.

Notice that it is meant to be off by default, and, indeed, for me,
it is off. Not sure why you are getting .pyc files in your
build directory.

Regards,
Martin