[Python-ideas] PEP x: Static module/package inspection

[Nathan Rice]

On Wed, Dec 28, 2011 at 5:15 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> user story PEPx.001:
> As a Python package maintainer, I find it bothersome to repeatedly write
> bolierplate code (e.g. setup.py) to package my single file module. The
> reason I should write setup.py is to provide version and description info.
> This info is already available in my module source code. So I need to either
> copy/paste the info from the module manually, or to import (and hence
> execute) my module during packaging and installation, which I don't want
> either, because modules are often installed with root privileges.

I agree this is a pain.  I also agree with Micheal that this is moreso
a packager issue.  Part of the problem is that I don't believe there
is a strong enough convention around writing modules with an eye to
being package tools accessible.  If there was a PEP on module metadata
for packaging tools to use for introspection, that might motivate
package tool authors to support automated packaging :) *HINT HINT*
Sphinx could also take advantage of some of it too.

> With this PEP, packing tool will be able to extract meta information from my
> module without executing it or without me manually copying version fields
> into some 'package configuration file'.
>
> user story PEPx.002:
> As a Python Application developer, I find it really complicated to provide
> plugin extension subsystem for my users. Users need a mechanism to switch
> between different versions of the plugin, and this mechanism is usually
> provided by external tool such as setuptools to manage and install multiple
> versions of plugins in local Python package repository. It is rather hard to
> create an alternative approach, because you are forced to maintain external
> meta-data about your plugin modules even in case it is already available
> inside the module.

See above.  Maintaining the same information twice is definitely a bad
thing, but we already have the ability to do everything required.
What is missing is good, strong conventions on module metadata
annotation that tool creators write to.

> With this PEP, Python Application will be able to inspect meta-data embedded
> inside of plugins before choosing which version to load. This will also
> provide a standard mechanism for applications to check modules returned by
> packaging tools without executing them. This will greatly simplify writing
> and debugging custom plugins loaders on different platforms.

Having more nuanced import behavior is something I can get behind.
Sure, I can wrap an import in a try except, and check the __version__
if is defined (after determining if it is a string/tuple/etc, and
possibly parsing it), but more nuanced behavior would certainly be
nice.  Being able to specify version in the import line (and have
multiple versions installed), being able to get fine grained exception
beyond ImportError (ParseError, anyone?), not having to worry that the
same file is being imported twice, that sort of stuff.

I'm +1 getting a module level metadata conventions PEP draft started.
I'm also +1 on taking a look at import behavior (though that is
tangential here).

Nathan