PEP 390 - new format from setup.cfg

[Tarek Ziadé]

Hey

this is the PEP for setup.cfg, as requested :
http://www.python.org/dev/peps/pep-0390

Please comment,

Tarek

--
Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[ianb]

The grammar in "Context-dependant sections" indicates possible EXPR
values.  Because the "in" operator is supported, I would assume that
tuples should also be allowed.

One aspect of the current setup.cfg is that it supports multiple
sections, for different setup.py commands or components.  This gives a
kind of namespacing.  I assume, but it isn't that specified, that any
section (not just "metadata") will be parsed the same way?

Presumably setup.py will just contain an empty call to setup()?  (I
assume at least setup.py will be allowed for, for backward
compatibility, even if it is not required.)

I believe this does not include the concept of extra requirements.
Possibly it could as a side-effect of some variable available to the
language.  Like:

  [metadata:'xmlrpc' in features]
  requires = lxml

Sets and the & operator could be useful for this.

The way variables are handled is unclear.  Presumably all variables
are cumulative.  But given:

  requires = Foo
  requires = Bar

What is the value of "requires"?  A list, a value with newlines?
Presumably you could also do:

  requires = Foo
      Bar

Anyway, we're diverging from INI semantics at this point, so it needs
to be specified how it works.

Is there a way to eliminate values?  Right now, for instance, if you
have "[build] home = /foo" in a distutils.cfg, there's no way to unset
that.  I'd like to see this functionality included.  Perhaps to delete
a specific value, but the simpler case of deleting a variable is
really all I want.



On Sun, Oct 11, 2009 at 5:17 PM, Tarek Ziadé <ziade.tarek@...> wrote:

> Hey
>
> this is the PEP for setup.cfg, as requested :
> http://www.python.org/dev/peps/pep-0390
>
> Please comment,
>
> Tarek
>
> --
> Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@...
> http://mail.python.org/mailman/listinfo/distutils-sig
>

--
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Floris Bruynooghe-2]

On Mon, Oct 12, 2009 at 12:17:10AM +0200, Tarek Ziadé wrote:
> this is the PEP for setup.cfg, as requested :
> http://www.python.org/dev/peps/pep-0390
>
> Please comment,

<, <=, >=, > and python_hexversion are not mentioned, is this
intentional?  (I'm not sure on what the result of feedback on this
was)

Secondly, where are spaces allowed in the section headers?  I'd be
tempted to write:

    [metadata: os_machine == 'i386']

But in all your examples you never have spaces after the ':'.  Would
it be worth being explicit about this?

Regards
Floris

--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Mon, Oct 12, 2009 at 2:29 AM, Ian Bicking <ianb@...> wrote:
> The grammar in "Context-dependant sections" indicates possible EXPR
> values.  Because the "in" operator is supported, I would assume that
> tuples should also be allowed.

"in" here is restricted to string. It was added so we could write things like:

'linux' in sys_platform  (where sys_platform can be linux2)

I'll add a note on that.

>
> One aspect of the current setup.cfg is that it supports multiple
> sections, for different setup.py commands or components.  This gives a
> kind of namespacing.  I assume, but it isn't that specified, that any
> section (not just "metadata") will be parsed the same way?

I guess yes, even if I don't see a use case yet for that.

>
> Presumably setup.py will just contain an empty call to setup()?  (I
> assume at least setup.py will be allowed for, for backward
> compatibility, even if it is not required.)

No because we might need to define extra options in setup()
that are not part of the metadata, like what is required the for the
sdist command
(package_data, scripts, package, etc)


>
> I believe this does not include the concept of extra requirements.
> Possibly it could as a side-effect of some variable available to the
> language.  Like:
>
>  [metadata:'xmlrpc' in features]
>  requires = lxml
>
> Sets and the & operator could be useful for this.

How would you define/provide "features" here ?

>
> The way variables are handled is unclear.  Presumably all variables
> are cumulative.  But given:
>
>  requires = Foo
>  requires = Bar
>
> What is the value of "requires"?  A list, a value with newlines?
> Presumably you could also do:
>
>  requires = Foo
>      Bar
>
> Anyway, we're diverging from INI semantics at this point, so it needs
> to be specified how it works.

Right, this needs to be defined. I would be in favor of the latter, to
stay ConfigParser
compatible.

>
> Is there a way to eliminate values?  Right now, for instance, if you
> have "[build] home = /foo" in a distutils.cfg, there's no way to unset
> that.  I'd like to see this functionality included.  Perhaps to delete
> a specific value, but the simpler case of deleting a variable is
> really all I want.

Do you have a syntax in mind for this ?

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Mon, Oct 12, 2009 at 11:01 AM, Floris Bruynooghe
<floris.bruynooghe@...> wrote:
> On Mon, Oct 12, 2009 at 12:17:10AM +0200, Tarek Ziadé wrote:
>> this is the PEP for setup.cfg, as requested :
>> http://www.python.org/dev/peps/pep-0390
>>
>> Please comment,
>
> <, <=, >=, > and python_hexversion are not mentioned, is this
> intentional?  (I'm not sure on what the result of feedback on this
> was)

That was the result of the feedback we had (see 'limitations' section)
for clarity.

The idea is to leave a string "python_version", and remove '>', '<' with no
python_hexversion.

Then, the day PEP 386 is accepted, we turn "python_version" into a Version()
object and we introduce '>', '<' and al.

>
> Secondly, where are spaces allowed in the section headers?  I'd be
> tempted to write:
>
>    [metadata: os_machine == 'i386']
>
> But in all your examples you never have spaces after the ':'.  Would
> it be worth being explicit about this?

Good point, I'll add this.

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Stanley A. Klein-2]

On Mon, October 12, 2009 12:24 am, Tarek Ziad? <ziade.tarek@...> wrote:
 ------------------------------
>
> Message: 2
> Date: Mon, 12 Oct 2009 00:17:10 +0200
> From: Tarek Ziad? <ziade.tarek@...>
> To: distutils-sig@...
> Subject: [Distutils] PEP 390 - new format from setup.cfg

> Hey
>
> this is the PEP for setup.cfg, as requested :
> http://www.python.org/dev/peps/pep-0390
>
> Please comment,
>
> Tarek
>

It isn't clear in the new format how one would set up a bdist_rpm for an
SE-Linux system (such as Fedora or Centos) that has required pyc and pyo
files to be included in the package.  In the past this has been done using
entries in setup.cfg.


Stan Klein



_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[ianb]

On Mon, Oct 12, 2009 at 4:45 AM, Tarek Ziadé <ziade.tarek@...> wrote:
> On Mon, Oct 12, 2009 at 2:29 AM, Ian Bicking <ianb@...> wrote:
>> The grammar in "Context-dependant sections" indicates possible EXPR
>> values.  Because the "in" operator is supported, I would assume that
>> tuples should also be allowed.
>
> "in" here is restricted to string. It was added so we could write things like:
>
> 'linux' in sys_platform  (where sys_platform can be linux2)

If you don't have tuples or <, >, etc, it seems like something like
"Python version 2.6 or higher" is hard to express.  You'd have to
enumerate 2.6, 2.7, and speculate on 2.8 and 2.9.

> I'll add a note on that.
>
>>
>> One aspect of the current setup.cfg is that it supports multiple
>> sections, for different setup.py commands or components.  This gives a
>> kind of namespacing.  I assume, but it isn't that specified, that any
>> section (not just "metadata") will be parsed the same way?
>
> I guess yes, even if I don't see a use case yet for that.

One use case for the current setup.cfg is for extensions, like
generating Sphynx documentation.  Those extensions can sometimes take
quite a lot of options, so they are best when partitioned into their
own section.  I'm also not sure whether [metadata] is intended to have
extensible variables, or a fixed set of variables.

>> Presumably setup.py will just contain an empty call to setup()?  (I
>> assume at least setup.py will be allowed for, for backward
>> compatibility, even if it is not required.)
>
> No because we might need to define extra options in setup()
> that are not part of the metadata, like what is required the for the
> sdist command
> (package_data, scripts, package, etc)

OK, so setup.cfg is for generating PKG-INFO, but installing a package
still involves running setup.py and some maybe-declarative code in
there.

>> I believe this does not include the concept of extra requirements.
>> Possibly it could as a side-effect of some variable available to the
>> language.  Like:
>>
>>  [metadata:'xmlrpc' in features]
>>  requires = lxml
>>
>> Sets and the & operator could be useful for this.
>
> How would you define/provide "features" here ?

I'm not sure.  With Setuptools the equivalent is "extras", like:

setup(name='foo',
    extras_require={'xmlrpc': ['lxml']})

Then if you do "easy_install foo[xmlrpc]" (or somehow require
foo[xmlrpc]) it will also install/require lxml.

If I was to say why this is a problem, I think it's because the
default is that there are no features for a package.  So someone
naively wants your package and installs it, but they don't get all the
features they thought the package provided (and which the package
actually *does* provide, but just doesn't have the prerequisite
libraries for -- since the package ships with the xmlrpc code, it's
just not working xmlrpc code).  There's also not a good way of seeing
what extras are provided, or what their purpose is.  So library
authors avoid the issue entirely and don't factor out requirements
into specific extras/features.  If there was a set of "default" extras
maybe it would be more workable.  I.e., "easy_install foo" installs
foo with all its default extras, and "easy_install foo[]" installs foo
without any extras (or you put the specific extras you want in []).

Anyway, the way extra requirements are serialized to disk is requires.txt, with:

  default_req1
  default_req2

  [extra]
  extra_req1
  ...

So, since the result involves multiple sections it wouldn't naturally
map to what you are proposing.

>> The way variables are handled is unclear.  Presumably all variables
>> are cumulative.  But given:
>>
>>  requires = Foo
>>  requires = Bar
>>
>> What is the value of "requires"?  A list, a value with newlines?
>> Presumably you could also do:
>>
>>  requires = Foo
>>      Bar
>>
>> Anyway, we're diverging from INI semantics at this point, so it needs
>> to be specified how it works.
>
> Right, this needs to be defined. I would be in favor of the latter, to
> stay ConfigParser
> compatible.

You still have to define how options are combined from multiple
sections, and what the resulting value is from the API.  That is, if
you have:

    [metadata]
    requires = Foo
        Bar

    [metadata:python_version == '2.4' or python_version== '2.3' or
python_version=='2.2']
    requires = BackwardCompat

Then what is the ultimate value of "requires"?  Is it
"Foo\nBar\nBackwardCompat" or ["Foo", "Bar", "BackwardCompat"], or
[Requirement.parse("Foo"), Requirement.parse('Bar"),
Requirement.parse("BackwardCompat")].

And given other variables (ones that perhaps distribute doesn't even
know about) how are they combined?

>> Is there a way to eliminate values?  Right now, for instance, if you
>> have "[build] home = /foo" in a distutils.cfg, there's no way to unset
>> that.  I'd like to see this functionality included.  Perhaps to delete
>> a specific value, but the simpler case of deleting a variable is
>> really all I want.
>
> Do you have a syntax in mind for this ?

Well, the way I added more meta-operations in Paste Deploy (which uses
ConfigParser) was to mess with the variable names.  So maybe:

    [metadata:python_version=="2.5"]
    del requires = Foo

It might have a value to delete a specific value (or line) from that
"requires" variable, or if empty it would clear that variable.  Since
ConfigParser doesn't order the variables, it would delete them from
"earlier" sections, not the current section.  This requires defining
what makes a section "earlier".  Or maybe it would delete "Foo" from
whatever the value of requires ends up being, or if you do "del
requires =" would make that section provide the only value for
requires.


Another thought: one thing distutils does but sometimes confuses me is
that it has boolean options (options which take no values, sometimes
with an option and an anti-option, e.g., --feature-foo and
--no-feature-foo) which turn into a single configuration variable with
a boolean value.  How that is supposed to work seems apropos (it's not
strictly syntax, but I don't feel like I can judge the syntax without
considering the full semantics of the configuration file, because the
semantics drive the actual use cases which should in turn be used to
judge the syntax).

--
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Mon, Oct 12, 2009 at 6:10 PM, Ian Bicking <ianb@...> wrote:
> If you don't have tuples or <, >, etc, it seems like something like
> "Python version 2.6 or higher" is hard to express.  You'd have to
> enumerate 2.6, 2.7, and speculate on 2.8 and 2.9.

python_version not in '2.3,2.4,2.5'

(it's not optimal, but enough I guess, until PEP 386 is accepted)

> One use case for the current setup.cfg is for extensions, like
> generating Sphynx documentation.  Those extensions can sometimes take
> quite a lot of options, so they are best when partitioned into their
> own section.  I'm also not sure whether [metadata] is intended to have
> extensible variables, or a fixed set of variables.

The variables are fixed so it works with a vanilla python and doesn't
require anything else
to run. Having extensible variables would break that idea and would just
make people move code they use to have in setup.py in another place imho.

>> No because we might need to define extra options in setup()
>> that are not part of the metadata, like what is required the for the
>> sdist command
>> (package_data, scripts, package, etc)
>
> OK, so setup.cfg is for generating PKG-INFO, but installing a package
> still involves running setup.py and some maybe-declarative code in
> there.
>

Yes, this is restricted to the Metadata fields.

>> How would you define/provide "features" here ?
>
> I'm not sure.  With Setuptools the equivalent is "extras", like:
>
> setup(name='foo',
>    extras_require={'xmlrpc': ['lxml']})
>
> Then if you do "easy_install foo[xmlrpc]" (or somehow require
> foo[xmlrpc]) it will also install/require lxml.
>

[...]
>  ...
>
> So, since the result involves multiple sections it wouldn't naturally
> map to what you are proposing.

That could be done I think as long as the extras are not calculated by
third-party code.

Let's say, we define an 'extras' variable, which value can be provided
when interpreting setup.cfg.

If could be described like this :

[metadata:'xmlrpc' in extras]
requires = lxml

The part that is unclear to me is how to list the extras a setup.cfg file has.

>> Right, this needs to be defined. I would be in favor of the latter, to
>> stay ConfigParser
>> compatible.
>
> You still have to define how options are combined from multiple
> sections, and what the resulting value is from the API.  That is, if
> you have:
>
>    [metadata]
>    requires = Foo
>        Bar
>
>    [metadata:python_version == '2.4' or python_version== '2.3' or
> python_version=='2.2']
>    requires = BackwardCompat
>
> Then what is the ultimate value of "requires"?  Is it
> "Foo\nBar\nBackwardCompat" or ["Foo", "Bar", "BackwardCompat"], or
> [Requirement.parse("Foo"), Requirement.parse('Bar"),
> Requirement.parse("BackwardCompat")].
>
> And given other variables (ones that perhaps distribute doesn't even
> know about) how are they combined?

Right, this needs clarification. In any case, I think using multiline
is a bad idea
because it'll break RCF 232 compatibility for the long_description field.

So i've updated the PEP with ',' separator.

>>> Is there a way to eliminate values?  Right now, for instance, if you
>>> have "[build] home = /foo" in a distutils.cfg, there's no way to unset
>>> that.  I'd like to see this functionality included.  Perhaps to delete
>>> a specific value, but the simpler case of deleting a variable is
>>> really all I want.
>>
>> Do you have a syntax in mind for this ?
>
> Well, the way I added more meta-operations in Paste Deploy (which uses
> ConfigParser) was to mess with the variable names.  So maybe:
>
>    [metadata:python_version=="2.5"]
>    del requires = Foo
>
> It might have a value to delete a specific value (or line) from that
> "requires" variable, or if empty it would clear that variable.  Since
> ConfigParser doesn't order the variables, it would delete them from
> "earlier" sections, not the current section.  This requires defining
> what makes a section "earlier".  Or maybe it would delete "Foo" from
> whatever the value of requires ends up being, or if you do "del
> requires =" would make that section provide the only value for
> requires.

That makes sense. It completes what we can do.

Also, I've discussed with MAL about this PEP, and he came up with the idea
that the conditions should be pushed in PKG-INFO as well. See
the latest change in PEP 390.

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[David Lyon]

On Mon, 12 Oct 2009 00:17:10 +0200, Tarek Ziadé <ziade.tarek@...>
wrote:
> Hey
>
> this is the PEP for setup.cfg, as requested :
> http://www.python.org/dev/peps/pep-0390
>
> Please comment,
>
> Tarek

Can I have assistance submitting an alternate PEP?

Generally speaking you never answer any email from me but in
this case I ask that you assist in respect to having a fair and
due process.

I have subscribed to peps@... but havent received an
email back. I have posted it to peps@....

Here is my PEP...

PEP: 0
Title: An improved python application/package setup system using setup.info
Version: 1.0
Last-Modified: 13-10-2009
Author: David Lyon
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 13-Oct-2009
Discussions-To: david.lyon@...


Preamble
--------

This document describes an improved way for application
and package developers to specify information for installation
to different systems compared to traditional method that uses
setup.py.


Abstract
--------

This PEP proposes a change to the way that applications
and libraries are installed in python, by using a new
file called setup.info rather than setup.py. To hold
installation information.

For example:

[setup]
name = artistflair
version = 1.2
description = artistflair is a package written in
    spare time to show colour variations.

[dependencies]
packages = pyopengl
    objectrelationalmapper >= 1.6

[dependencies python<=2.4]
packages = lxml >= 2.5

[dependencies windows]
packages = win32com

[dependencies linux]
packages = pyodbc

[Application]
scripts = artisticflairgui.py

[configuration]
files = artisticflair.conf

[datafiles]
files = artisticdb.db
directory = db

[Documentation]
directory = docs
url = index.html

[preinstall]
script = checksystem.py

[postinstall linux]
script = builddocumentation.py

[uninstall]
script = uninstallcleanup.py

Rationale
---------

Traditionally, python has used a setup.py to
perform package installation.

Metadata has been hardcoded into setup.py
which is then passed to distutils and the
installation is performed.

Time has revealed limitations with the setup.py
system and this pep proposes a more flexible and
powerful system for installation using setup
information stored as parameters within a
setup.info file.

The advantages of this new approach are:

 - a clean way to handle variations due to different
   operating systems.

 - a clean way to specify package dependencies
   (including conditional dependencies based
    on operating system and python interpretor
    version)

 - a way to handle pre and post installation
   processing.

 - a way to handle package/application uninstallation

A boilerplate setup.py will be provided to accompany
setup.info file on platforms where distutils isn't
patched. This would provide backward compatability
with previous python versions.

The setup.info file will be based on the the standard
python ConfigParser file format format.

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.


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

What this means is that for all platforms, package objectmapper
>= version 2.5 is required. However on windows, there's an
additional depency that win32com is required. On Linux or Mac,
win32com won't be required.

Then, on linux the package pyodbc is required, but not on
the mac or windows.

Therefore the above list gives us the following dependency
matrix:

platform       windows linux   mac
objectmapper     yes    yes    yes
win32com         yes    no     no
pyodbc           no     yes    no


Thus we end up with a way of conditionally being able to
specify sections that reflect the differences in underlying
platforms.

The specifier isn't limited to just the dependency section
and can be applied to provide conditional installation
on any of the following sections:

 dependencies preinstall postinstall scripts
 application documentation uninstall datafiles.

Operating system is one of the following values
but also may contain a version number which is
used to denote the operating system:
 windows[-('95','98','me','2000','xp','vista','7')]
 mac ('9.5','10.0')
 linux
 linux[-('suse','redhat','ubuntu')]
 symbion
 wince

This would provide ways to handle challenges that
arrise for particular operating system versions.

[postinstall windows=2000]
script=registrycorrect.py

preinstall linux-redhat<=6]
script=youneedtoupgrade.py

PythonVersion is one of the following

 python ('2.3','2.4','2.5','2.6','2.7','3.0,'3.1')
 ironpython
 jython

So an example might be:

[dependencies python<=2.4]
packages = lxml

Package Metadata
----------------

Traditionally, package metadata has been stored within
the setup.py program file as hardcoded variables.

#!/usr/bin/env python

from distutils.core import setup

setup(name='artisticflair',
      version='1.0',
      description='Demonstration of color usage',
      author='David Lyon',
      author_email='dlyon@...',
      url='http://www.python.org',

This PEP proposes moving the metadata from setup.py
into setup.info to the section known as setup.

[setup]
name = Artisticflair
version = 1.0
description = Demonstration of color usage
author = David Lyon
author_email = dlyon@...
url = http://www.python.org

Readers may question why this information is here
in addition to being in the PKG-INFO file.

The reason is that it is intended that the PKG-INFO
file could be created with the metadata from this section
by reading the [setup] section and writing the
values sequentially.

In a development environment, reading a version number
and updating it when the file is in configparser format
is much easier than manually editing the setup.py file.

Therefore, many tasks relating to the production of
documentation, help files and the like will benefit
greatly from the introduction of a setup.info file.

The existance of a correspending PKG-INFO file will
be complement the setup.info file. It's expected
that the PKG-INFO file will be created from the
metadata information held inside the setup.info file.

This will preserve backwards compatability.


Dependency Handling [dependencies]
----------------------------------

To handle package/application dependencies, it is proposed
that there be a section within setup.info called
'dependencies' with a multiline list 'packages'. ie:

[dependencies]
packages = numpy >= 1.1
      biolife > 1.5

Each package consists of a single line entry, with an
optional operator ("==",">=",">") and a version string.

There are many real world examples where dependencies
changed based on the destination platform. So the
section name can be changed so that additional
dependencies can be added for specific platforms.

[depencies linux]
packages = pyodbc

[dependencies windows python<=2.4]
packages = lxml >= 2.5


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

It's often neccessary when doing an install to
run a script to probe the system to determine if
an installation is at all possible.

Here's the simplest use case, specifying a script
that runs to check the system:

[preinstall]
script = checksystem.py

In the following case, different scripts are run
depending on the operating system:

[preinstall]
script = checksystem.py

[preinstall linux]
script = checkmylinux.sh

[preinstall mac-os/x]
script = checkmymac.py

[preinstall windows]
script = checkmypc.bat

When calling the script, a command line parameter
is supplied. That parameter is destination directory
to which it's calculated that installation will
go to.

For example:

   checkmysystem.py /usr/local/python2.5/lib/site-packages/artistflair-1.2

or on windows:

   checkmysystem.py "c:\python2.5\lib\site-packages\artistflair-1.2"

If scripts return a 0 return code, installation
will proceeed. If a non-zero return code is
encountered, installation won't proceed and the
user will be notified.


Post Install Processing [postinstall]
-------------------------------------

After install, that is, after the program/package directories are
created and all the files are copied, it's often neccessary to go
off and do initialisation of some sort.

Typically, it's likely to be something such as:

 - generate/compile documentation (man pages or sphinx files)

 - migrate a users old database

 - remove old versions of an application

 - register files with the operating system

To accomplish this, postinstall processing support is required.

[postinstall]
script = builddocumentation.py

[postinstall linux]
script = buildmanpages.py

[postinstall mac]
script = makeitlookniceforme.py


Application Scripts [Application]
---------------------------------

Traditionally, setup.py hasn't provided ready support for the
installation of applications.

This PEP proposes that the task of registering python applications
becomes much simpler with the addition of an application section
specifically oriented to assist developers get their applications
registered on the user desktop.

In simple terms, what this section is about is registering the
python scripts with the window manager. On Linux - that might
be KDE or Gnome, on Windows - the program manager, and on the
Mac - the desktop.

[Application]
scripts = artisticflairgui.py

The above example would cause the application to be installed
in an "artistflair" folder (derived from [setup]/name) created
on the window manager.


Configuration files [Configuration]
-----------------------------------

Most real world applications carry with them a configuration
file of some sort. It is certainly not mandatory that this
section exists but if it does it will provide a way to
carry configuration files to their appropriate end
destination.

Where configuration files are actually stored is different
between operating platforms. On Linux and Mac, files go
to a user directory, or possibly /etc. On windows they
go to \Documents and Settings\user\application data\myapp.

[configuration]
files = artisticflair.conf

By specifying the configuration file, the system will
ensure that the configuration file goes to the correct
place.


Data Files [Datafiles]
----------------------

In any application, data files may be an install option.

This section specifies what the datafiles are and the
name of the subdirectory that they will be placed in.

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


Documentation
-------------

Most projects carry documentation of some sort.

More importantly, a developer wants to make it very
easy for the user to be able to access that documentation.

By specifying the documentation files in the documentation
section, shortcuts to the documentation can then be created
in the window manager to enable the user to easily access
them.

Traditionally, documentation has been built offline and
kept in with the package. With the Internet, there's been
a move to online documentation. The mechanism described
here handles both very simply.

[Documentation]
directory = docs
url = index.html
readme = readme.txt

In the above snippet, all documentation is locally stored
and has been placed in a directory called 'docs'. At install
time, that entire directory and subdirectores will be
copied to the local system.

Within the artisticflair/docs subdirectory, the main
documentation file is index.html. A readme file is also
provided. Both these will have a shortcut created for
them within the local window manager.

For online documentation, simply point the documentation
url to an online link.

[Documentation]
url = www.python.org/docs

The last example shows how to do documentation for different
platforms. For example windows users may be disoriented
when given screen shots to mac software, and vice-versa.

There is a difference in logic with operating system and
python version handling in the section names for 'documentation'.

The difference is that documentation is more specific and
there is usually only one copy of documentation.

For example, if we are on the mac, we only want the mac
documentation shown. We don't want the linux documentation
to be available (unlesss we decide to do that).

Therefore, the documentation section mechanism allows
us to clearly seperate different documentation for
different platforms.

[Documentation]
url = index.html

[Documentation mac]
url = www.nourl.at/artisticflairmac.html

[Documentation linux]
url = www.nourl.at/artisticflairlin.html

[Documentation linux-kde]
url = www.nourl.at/artisticflairlinkde.html

[Documentation windows]
url = www.nourl.at/artisticflairwin.html

[Documentation windows-vista]
url = www.nourl.at/artisticflairwinvista.html

The final accomodation is the language prefix. For
example to specify multilingual documentation:

[Documentation]
url = index.html
url-es = index_es.html
url-fr = index_fr.html
url-de = index_de.html


Uninstall
---------

This section is to provide a script to do a final
cleanup before uninstall takes place.

[uninstall]
script = dropmytables.py

It's expected that setup.py will perform the actual
deinstallation.


Processing Sequence
-------------------

This proposal suggests that setup.py be enhanced to allow
reading of the metadata from setup.info as package/application
install time.

A boilerplate setup.py will be made available to read data
from the setup.info file, before passing control to distutils
to perform the package installation.

Therefore, the python tradition of 'python setup.py install' can
be preserved.


Acknowdgements
--------------

All the people on the distutils mailing list who asked for
features.

Copyright
---------

This document has been placed in the public domain.
Acknowledgements


_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Tue, Oct 13, 2009 at 8:18 AM, David Lyon <david.lyon@...> wrote:

> On Mon, 12 Oct 2009 00:17:10 +0200, Tarek Ziadé <ziade.tarek@...>
> wrote:
>> Hey
>>
>> this is the PEP for setup.cfg, as requested :
>> http://www.python.org/dev/peps/pep-0390
>>
>> Please comment,
>>
>> Tarek
>
> Can I have assistance submitting an alternate PEP?
>
> Generally speaking you never answer any email from me but in
> this case I ask that you assist in respect to having a fair and
> due process.

That is not true. If you look at the distutils-archive I've answered
to most of your questions.

>
> I have subscribed to peps@... but havent received an
> email back. I have posted it to peps@....
>
> Here is my PEP...

Why are you doing a similar PEP, what's the point ? You've already helped a bit.

I suggest that you help us finishing in the existing PEP 390 instead,
by proposing changes.

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[cdavid]

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
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[David Lyon]

On Tue, 13 Oct 2009 10:36:12 +0200, Tarek Ziadé <ziade.tarek@...>
wrote:
> Why are you doing a similar PEP, what's the point ? You've already helped
a
> bit.

Tarek,

I championed the use of static metadata on the distutils mailing list
before you picked it up. Don't you remember?

The reason that I am doing an alternate PEP is because it contains
improvements that would be very useful on windows and linux.

A fair and open development process should mean that people are
able to freely contribute their ideas and have them evaluated
on the merits of the idea.

> I suggest that you help us finishing in the existing PEP 390 instead,
> by proposing changes.

If I see things I can help with, then I'm happy to do that...

David


_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Tue, Oct 13, 2009 at 11:16 AM, David Lyon <david.lyon@...> wrote:

> On Tue, 13 Oct 2009 10:36:12 +0200, Tarek Ziadé <ziade.tarek@...>
> wrote:
>> Why are you doing a similar PEP, what's the point ? You've already helped
> a
>> bit.
>
> Tarek,
>
> I championed the use of static metadata on the distutils mailing list
> before you picked it up. Don't you remember?

Frankly, I don't. The first time we've mentioned static metadata was
at Pycon last year.
The first one who mentioned the idea was Eric IIRC, then Matthias and
Tres worked on it.

But who cares ?  I am not claiming any ownership on ideas. I am not
tracking either who
threw which idea. But if someone cares, speak up : I'll detail who participated
in the Acknowledgment section.

I just happen to be the one maintaining PEP 390 and I am trying to collect
ideas here because I am maintaining Distutils so I'll be the one who
will apply the changes there.

>
> The reason that I am doing an alternate PEP is because it contains
> improvements that would be very useful on windows and linux.
>
> A fair and open development process should mean that people are
> able to freely contribute their ideas and have them evaluated
> on the merits of the idea.

That's exactly how PEP 390 was built. The process is far from being
perfect though,
maybe some ideas didn't make it through. But that's how it goes.

>
>> I suggest that you help us finishing in the existing PEP 390 instead,
>> by proposing changes.
>
> If I see things I can help with, then I'm happy to do that...

Great then, I am looking forward for its improvements.

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Floris Bruynooghe-2]

On Tue, Oct 13, 2009 at 02:18:11AM -0400, David Lyon wrote:
> This PEP proposes a change to the way that applications
> and libraries are installed in python, by using a new
> file called setup.info rather than setup.py. To hold
> installation information.

This seems to propose a whole build system, while PEP390 only aims for
static metadata.  Not restricting it to static metadata makes the
domain a lot wider and complicated as shown by countless previous
discussions on this list (several of these things have been outlined
before).  Since the problem domain is so huge it will take a very long
time to come up with a stable version that addresses all issues
adequately, something which this PEP sidesteps solving the problem it
targets in a sensible and contained way.

It certainly is a laudable goal to come up with such a build system
but I don't think it can be seen as *instead of* the metatdata PEP.
IMHO such a system should be using the static metadata from whatever
PEP 390 will become.


Regards
Floris
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Tue, Oct 13, 2009 at 12:30 PM, Floris Bruynooghe
<floris.bruynooghe@...> wrote:

> On Tue, Oct 13, 2009 at 02:18:11AM -0400, David Lyon wrote:
>> This PEP proposes a change to the way that applications
>> and libraries are installed in python, by using a new
>> file called setup.info rather than setup.py. To hold
>> installation information.
>
> This seems to propose a whole build system, while PEP390 only aims for
> static metadata.  Not restricting it to static metadata makes the
> domain a lot wider and complicated as shown by countless previous
> discussions on this list (several of these things have been outlined
> before).  Since the problem domain is so huge it will take a very long
> time to come up with a stable version that addresses all issues
> adequately, something which this PEP sidesteps solving the problem it
> targets in a sensible and contained way.
>
> It certainly is a laudable goal to come up with such a build system
> but I don't think it can be seen as *instead of* the metatdata PEP.
> IMHO such a system should be using the static metadata from whatever
> PEP 390 will become.

If wanted, I can go ahead I create a new PEP for David's proposal. And
David can work it out
using PEP 390 references maybe

let me know

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[ianb]

On Mon, Oct 12, 2009 at 11:34 AM, Tarek Ziadé <ziade.tarek@...> wrote:
> On Mon, Oct 12, 2009 at 6:10 PM, Ian Bicking <ianb@...> wrote:
>> If you don't have tuples or <, >, etc, it seems like something like
>> "Python version 2.6 or higher" is hard to express.  You'd have to
>> enumerate 2.6, 2.7, and speculate on 2.8 and 2.9.
>
> python_version not in '2.3,2.4,2.5'
>
> (it's not optimal, but enough I guess, until PEP 386 is accepted)

Given the small number of values available, string comparison works
fine in this case.  Is there a situation when the data would be
dependent on a package version other than Python's?

>> One use case for the current setup.cfg is for extensions, like
>> generating Sphynx documentation.  Those extensions can sometimes take
>> quite a lot of options, so they are best when partitioned into their
>> own section.  I'm also not sure whether [metadata] is intended to have
>> extensible variables, or a fixed set of variables.
>
> The variables are fixed so it works with a vanilla python and doesn't
> require anything else
> to run. Having extensible variables would break that idea and would just
> make people move code they use to have in setup.py in another place imho.

It should at least be allowed to have other values with a warning,
similar to keyword arguments to setup() that are unknown.  This lets
the format be forward compatible with new variables.  E.g., if in
Python 2.8 there's a new variable, people can just dump it in.

>>> How would you define/provide "features" here ?
>>
>> I'm not sure.  With Setuptools the equivalent is "extras", like:
>>
>> setup(name='foo',
>>    extras_require={'xmlrpc': ['lxml']})
>>
>> Then if you do "easy_install foo[xmlrpc]" (or somehow require
>> foo[xmlrpc]) it will also install/require lxml.
>>
> [...]
>>  ...
>>
>> So, since the result involves multiple sections it wouldn't naturally
>> map to what you are proposing.
>
> That could be done I think as long as the extras are not calculated by
> third-party code.
>
> Let's say, we define an 'extras' variable, which value can be provided
> when interpreting setup.cfg.
>
> If could be described like this :
>
> [metadata:'xmlrpc' in extras]
> requires = lxml
>
> The part that is unclear to me is how to list the extras a setup.cfg file has.

There needs to be some enumeration of extras, yes.  And there really
needs to be more metadata than Setuptools allows for -- extras should
have at least a readable description.  So wherever they are defined,
there should be room for that documentation as well.

>> And given other variables (ones that perhaps distribute doesn't even
>> know about) how are they combined?
>
> Right, this needs clarification. In any case, I think using multiline
> is a bad idea
> because it'll break RCF 232 compatibility for the long_description field.

Oh... long_description -- I forgot about that.  How will that be dealt
with?  I now typically do something like this in setup.py:

  long_desc = open(os.path.join(os.path.dirname(__file__), 'docs',
'index.txt')).read()
  long_desc = long_desc.split('..contents::', 1)[1].strip()
  setup(..., long_description=long_desc)

Keeping the long description in setup.py (or in setup.cfg) is not
something I want to do.  It would be even worse in setup.cfg than it
is in setup.py.  Also ConfigParser eats leading whitespace (I believe
that's also a problem with the PKG-INFO format), which breaks ReST.
(I assume the "register" command does something other than uploading
PKG-INFO to get long_description in place?)

(Come to think of it, I'm not actually sure what we're accomplishing
with this declarative metadata; "setup.py --name" is too minimal, but
some new "setup.py metadata" command that dumps everything isn't hard
to imagine; what are the *real* advantages of this new proposal?  If I
have to use a build process to build my setup.cfg, then absolutely
nothing will be accomplished.  And is the complexity all just because
sometimes people need to use version-specific requirements?)

--
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Bicking wrote:

> On Mon, Oct 12, 2009 at 4:45 AM, Tarek Ziadé <ziade.tarek@...> wrote:
>> On Mon, Oct 12, 2009 at 2:29 AM, Ian Bicking <ianb@...> wrote:
>>> The grammar in "Context-dependant sections" indicates possible EXPR
>>> values.  Because the "in" operator is supported, I would assume that
>>> tuples should also be allowed.
>> "in" here is restricted to string. It was added so we could write things like:
>>
>> 'linux' in sys_platform  (where sys_platform can be linux2)
>
> If you don't have tuples or <, >, etc, it seems like something like
> "Python version 2.6 or higher" is hard to express.  You'd have to
> enumerate 2.6, 2.7, and speculate on 2.8 and 2.9.
>
>> I'll add a note on that.
>>
>>> One aspect of the current setup.cfg is that it supports multiple
>>> sections, for different setup.py commands or components.  This gives a
>>> kind of namespacing.  I assume, but it isn't that specified, that any
>>> section (not just "metadata") will be parsed the same way?
>> I guess yes, even if I don't see a use case yet for that.
>
> One use case for the current setup.cfg is for extensions, like
> generating Sphynx documentation.  Those extensions can sometimes take
> quite a lot of options, so they are best when partitioned into their
> own section.  I'm also not sure whether [metadata] is intended to have
> extensible variables, or a fixed set of variables.
>
>>> Presumably setup.py will just contain an empty call to setup()?  (I
>>> assume at least setup.py will be allowed for, for backward
>>> compatibility, even if it is not required.)
>> No because we might need to define extra options in setup()
>> that are not part of the metadata, like what is required the for the
>> sdist command
>> (package_data, scripts, package, etc)
>
> OK, so setup.cfg is for generating PKG-INFO, but installing a package
> still involves running setup.py and some maybe-declarative code in
> there.
>
>>> I believe this does not include the concept of extra requirements.
>>> Possibly it could as a side-effect of some variable available to the
>>> language.  Like:
>>>
>>>  [metadata:'xmlrpc' in features]
>>>  requires = lxml
>>>
>>> Sets and the & operator could be useful for this.
>> How would you define/provide "features" here ?
>
> I'm not sure.  With Setuptools the equivalent is "extras", like:
>
> setup(name='foo',
>     extras_require={'xmlrpc': ['lxml']})
>
> Then if you do "easy_install foo[xmlrpc]" (or somehow require
> foo[xmlrpc]) it will also install/require lxml.
>
> If I was to say why this is a problem, I think it's because the
> default is that there are no features for a package.  So someone
> naively wants your package and installs it, but they don't get all the
> features they thought the package provided (and which the package
> actually *does* provide, but just doesn't have the prerequisite
> libraries for -- since the package ships with the xmlrpc code, it's
> just not working xmlrpc code).  There's also not a good way of seeing
> what extras are provided, or what their purpose is.  So library
> authors avoid the issue entirely and don't factor out requirements
> into specific extras/features.  If there was a set of "default" extras
> maybe it would be more workable.  I.e., "easy_install foo" installs
> foo with all its default extras, and "easy_install foo[]" installs foo
> without any extras (or you put the specific extras you want in []).
>
> Anyway, the way extra requirements are serialized to disk is requires.txt, with:
>
>   default_req1
>   default_req2
>
>   [extra]
>   extra_req1
>   ...
>
> So, since the result involves multiple sections it wouldn't naturally
> map to what you are proposing.
>
>>> The way variables are handled is unclear.  Presumably all variables
>>> are cumulative.  But given:
>>>
>>>  requires = Foo
>>>  requires = Bar
>>>
>>> What is the value of "requires"?  A list, a value with newlines?
>>> Presumably you could also do:
>>>
>>>  requires = Foo
>>>      Bar
>>>
>>> Anyway, we're diverging from INI semantics at this point, so it needs
>>> to be specified how it works.
>> Right, this needs to be defined. I would be in favor of the latter, to
>> stay ConfigParser
>> compatible.
>
> You still have to define how options are combined from multiple
> sections, and what the resulting value is from the API.  That is, if
> you have:
>
>     [metadata]
>     requires = Foo
>         Bar
>
>     [metadata:python_version == '2.4' or python_version== '2.3' or
> python_version=='2.2']
>     requires = BackwardCompat
>
> Then what is the ultimate value of "requires"?  Is it
> "Foo\nBar\nBackwardCompat" or ["Foo", "Bar", "BackwardCompat"], or
> [Requirement.parse("Foo"), Requirement.parse('Bar"),
> Requirement.parse("BackwardCompat")].
>
> And given other variables (ones that perhaps distribute doesn't even
> know about) how are they combined?

Hmm, setuptools already has a concept of "Features" (see
setuptools.dist.Feature).  Is that sense relevant here?

>>> Is there a way to eliminate values?  Right now, for instance, if you
>>> have "[build] home = /foo" in a distutils.cfg, there's no way to unset
>>> that.  I'd like to see this functionality included.  Perhaps to delete
>>> a specific value, but the simpler case of deleting a variable is
>>> really all I want.
>> Do you have a syntax in mind for this ?

Excluding a Feature causes packages to be dropped (e.g., from sdist /
bdist operations).

> Well, the way I added more meta-operations in Paste Deploy (which uses
> ConfigParser) was to mess with the variable names.  So maybe:
>
>     [metadata:python_version=="2.5"]
>     del requires = Foo
>
> It might have a value to delete a specific value (or line) from that
> "requires" variable, or if empty it would clear that variable.  Since
> ConfigParser doesn't order the variables, it would delete them from
> "earlier" sections, not the current section.  This requires defining
> what makes a section "earlier".  Or maybe it would delete "Foo" from
> whatever the value of requires ends up being, or if you do "del
> requires =" would make that section provide the only value for
> requires.
>
>
> Another thought: one thing distutils does but sometimes confuses me is
> that it has boolean options (options which take no values, sometimes
> with an option and an anti-option, e.g., --feature-foo and
> --no-feature-foo) which turn into a single configuration variable with
> a boolean value.  How that is supposed to work seems apropos (it's not
> strictly syntax, but I don't feel like I can judge the syntax without
> considering the full semantics of the configuration file, because the
> semantics drive the actual use cases which should in turn be used to
> judge the syntax).

- --
===================================================================
Tres Seaver          [phone]          tseaver@...
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrUwZQACgkQ+gerLs4ltQ47EgCfddqCE/g7HT5Kmfay+/+KhJMp
UHEAoLWAqxJkUDk4UsxBTbfgRafiigKu
=iH89
-----END PGP SIGNATURE-----

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[David Lyon]

On Tue, 13 Oct 2009 19:01:30 +0200, Tarek Ziadé <ziade.tarek@...>
wrote:

> If wanted, I can go ahead I create a new PEP for David's proposal. And
> David can work it out
> using PEP 390 references maybe
>
> let me know

Thank you Tarek,

I appreciate it.

Good management decision :-)

David
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Tue, Oct 13, 2009 at 11:20 PM, David Lyon <david.lyon@...> wrote:

> On Tue, 13 Oct 2009 19:01:30 +0200, Tarek Ziadé <ziade.tarek@...>
> wrote:
>
>> If wanted, I can go ahead I create a new PEP for David's proposal. And
>> David can work it out
>> using PEP 390 references maybe
>>
>> let me know
>
> Thank you Tarek,
>
> I appreciate it.

So is that a yes ?

Tarek.
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[David Lyon]

On Tue, 13 Oct 2009 23:26:57 +0200, Tarek Ziadé <ziade.tarek@...>
wrote:

>>> If wanted, I can go ahead I create a new PEP for David's proposal. And
>>> David can work it out
>>> using PEP 390 references maybe
>>>
>>> let me know
>>
>> Thank you Tarek,
>>
>> I appreciate it.
>
> So is that a yes ?

I will answer offlist..

Thanks Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig