[Distutils] Alternate static metadata PEP submission...

[David Cournapeau]

Hi David,

David Lyon wrote:
> The setup.info file will be based on the the standard 
> python ConfigParser file format format.

You should develop on that, and compare against the current proposal
(the one written by Tarek and folks on distutils ML, PEP 390). I am in
favor of a richer 'static metadata' format, and don't really like where
the current PEP 390 is going, but it should be considered as the
"default" against which your proposal will be compared.

In particular, what's the point of ConfigParser format for a new file ?
It brings very few things compared to a format written from scratch, and
a lot of trouble (lack of proper variable definition, conditional and
nesting, for example). In PEP 390, the rationale is backward compatibility.

I also think your proposal would be stronger if you compared with
existing formats (e.g. rpm .spec, haskell .cabal). Python is behind
those systems on that point (from time and features POV), so a look at
prior art is a good idea:

    http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html
    http://www.rpm.org/max-rpm/ch-rpm-inside.html

There are other systems obviously.

>
> Adantages for using setup.info
> ------------------------------
>
>  1) It's easier to extend past the simplest use case
>
>  2) It's more developer friendly.
>
>  3) Provides an easier way to specify package dependencies
>
>  4) Provides a portable setup system across platforms
>
>  5) Easier to integrate within the development build
>     process where handling version numbers can often
>     be a challenge.
>

How so ? You need to provide examples of what is missing compared to
what's available in python now.


>
> Section Name Construction
> -------------------------
>
> The setup.info file is built as a standard configparser
> format file.
>
> Section names are built from a combination of a specifier
> then an option operating system name and finally an
> optional python version specifier.
>
> The following shows a very powerful way to build conditional
> installation for different operating systems and platforms
> that starts from very simple and can be extended with effort
> into the very complex.
>
> Most developers will choose the simplest option.
>
> Sections are built in the following format
>
>  specifier [operating_system] [pythonversion]
>
> A simple real world example might be:
>
> [dependencies]
> packages = objectmapper >= 2.5
>
> [dependencies windows]
> packages = win32com
>
> [dependencies linux]
> packages = pyodbc

Is there a rationale for limiting yourself to platform and python
version ? You may need to condition on other things (debugging may come
to mind, for example).

>
>
> Pre Installation Processing [preinstall]
> ----------------------------------------
>

In general, I think the notions pre-install/etc... are sorely needed,
but I am not sure they belong here. A precise definition and protocol
for what exactly is pre-install, pre-build, etc... is needed. This
brings the format extensibility capability - you should also consider
versioning the file format.

> [datafiles]
> files = artisticdb.dbf
>     artisticdb.mdx
>     authors.dbf
>     authors.mdx
> directory = db

How would you handle the case where you have several data directories ?
Concerning data files, the notion is too vague IMHO - I know that's the
notion used by distutils, but on linux at least, you need to consider
icons vs images vs doc (man vs html vs info vs ...). It should not be
mandatory for people who don't care, though.

cheers,

David