Re: [Distutils] Static metadata using setup.cfg
Chris Withers wrote: Tarek Ziadé wrote: [setup.cfg] long_description_path: README.txt long_description_path can't be added in the final PKG-INFO because we want a self-contained metadata static file that doesn't require an extra resource (like an external file) Why this requirement? Where this external file would it be located ? There's just *one* metadata file that contains everything. Fine, so when you generate setup.cfg from setup.cfg.in, process the long_description_path at that point and only insert the resulting long_description in setup.cfg . Exactly. And I'll probably not use a setup.cfg.in, I'll have some other mechanism for creating setup.cfg (from a variety of company-specific config files) for my own internal packages. But it won't make a difference, as long as a correct setup.cfg gets generated. Which is why I think that while setup.cfg.in might be useful for many people, it's not the important part. It's setup.cfg that needs to be nailed down. Eric. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Tarek Ziadé wrote: [setup.cfg] long_description_path: README.txt long_description_path can't be added in the final PKG-INFO because we want a self-contained metadata static file that doesn't require an extra resource (like an external file) Why this requirement? Where this external file would it be located ? There's just *one* metadata file that contains everything. Fine, so when you generate setup.cfg from setup.cfg.in, process the long_description_path at that point and only insert the resulting long_description in setup.cfg . cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Fri, Sep 11, 2009 at 4:03 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> The practice in the community is to create the long_description field
>> using a separate reStructuredText file
>> and reaching it in setup.py like this for example:
>>
>> long_description = open('README.txt').read()
>>
>> Having a callable that provides this feature in the template allows
>> writing:
>>
>> """
>> [setup.cfg]
>>
>> long_description: {$ long_description('README.txt') $}
>> """
>
> Exactly, so why have this complicated templating nonesense rather than just
> having:
>
> [setup.cfg]
>
> long_description_path: README.txt
>
>
>> long_description_path can't be added in the final PKG-INFO because
>> we want a self-contained metadata static file that doesn't require an
>> extra resource (like an external file)
>
> Why this requirement?
Where this external file would it be located ?
There's just *one* metadata file that contains everything.
People are injecting files in it when they build the distribution and sometime
don't even ship it with the archive.
If you put a path you can't be sure that the file behind this path
will be available
on the system that reads setup.cfg.
And it would break the idea that we can have static metadata without
further processing the package (by installing it or opening its files)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Tarek Ziadé wrote:
The practice in the community is to create the long_description field
using a separate reStructuredText file
and reaching it in setup.py like this for example:
long_description = open('README.txt').read()
Having a callable that provides this feature in the template allows writing:
"""
[setup.cfg]
long_description: {$ long_description('README.txt') $}
"""
Exactly, so why have this complicated templating nonesense rather than
just having:
[setup.cfg]
long_description_path: README.txt
long_description_path can't be added in the final PKG-INFO because
we want a self-contained metadata static file that doesn't require an
extra resource (like an external file)
Why this requirement?
If this really is that strict, then only allow long_description_path in
setup.cfg.in
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Thu, 10 Sep 2009 12:07:30 +1200, Greg Ewing
wrote:
> David Lyon wrote:
>
>> or just..
>>
>> [requires linux2]
>> ...
>>
>> [requires win32]:
>> ...
>
> Perhaps, if the sets of "tokens" used in the various fields
> one might be interested in are disjoint. It would require
> more intelligence from tools processing the data, though,
> and might be harder to extend to accommodate future
> requirements. Explicit might be better than implicit here.
Another example,
instead of say:
"""
${if python_version < '2.5':}$
install_requires: jsonlib
${:else:}$
install_requires: lxml
${:endif}$
"""
something like this:
"""
[setup]
name = mywebframework
version = 1.5
[python_version < '2.5']
install_requires = jasonlib
[python_version >= '2.5']
install_requires = lxml
"""
David
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Thu, 10 Sep 2009 12:07:30 +1200, Greg Ewing wrote: >> or just.. >> >> [requires linux2] >> ... >> >> [requires win32]: >> ... > > Perhaps, if the sets of "tokens" used in the various fields > one might be interested in are disjoint. It would require > more intelligence from tools processing the data, though, > and might be harder to extend to accommodate future > requirements. Explicit might be better than implicit here. It was a quick hack... Usually when installing, different platforms require special tweeking. What I mean is that on say (weird) platform Z for some reason some basic thing that is on every other platform isn't on it. So what I mean is: """ [setup] name=mywebframework version=1.5 [dependencies] packages = mywebtemplates >= 1.5 objectmapper >= 2.1 [dependencies linux2] packages = pyopenssl > 1.0 pyodbc >= 1.5 [dependencies win32] packages = win32com >= 1.1 """ So, what this means is that mywebframework always requires mywebtemplates, but when it is running on linux it needs pyopenssl, and when it is on win32 it requires win32com. On win32, there is odbc built in. On linux there is not. This is a fairly real world example of having different dependencies on different platforms. David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
David Lyon wrote: or just.. [requires linux2] ... [requires win32]: ... Perhaps, if the sets of "tokens" used in the various fields one might be interested in are disjoint. It would require more intelligence from tools processing the data, though, and might be harder to extend to accommodate future requirements. Explicit might be better than implicit here. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Tarek Ziadé wrote:
long_description: {$ long_description('README.txt') $}
A couple of thoughts:
1. Is there anything about this function that would
restrict it's use to the long_description field, or
could it be called something more general like
"from_file" and used in other contexts?
2. I'm against any syntax in the setup.cfg file that
resembles line noise (as the {$ $} does to my eyes).
--
Greg
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Wed, Sep 9, 2009 at 1:31 AM, Greg Ewing wrote:
> Tarek Ziadé wrote:
>
>> In that case, if we want to keep a configparser-compatible file, we
>> need to find another
>> way to express these if/else parts, which will probably lead to a
>> complex, non natural
>> syntax.
>
> Maybe the conditions could be expressed in the
> section headers?
>
> [requires platform="linux"]
> ...
>
> [requires platform="win32"]:
> ...
>
> Then it's not so much if-then-else logic as just
> tagging parts of the file with conditions under
> which they apply.
The problem is that we need more complex conditions like:
"platform == linux and python >= 2.5"
in that case, the ConfigParser format is making it hard to do it
like you've described, unless the section is the full expression :
[requires platform="linux" and python >="2.5"]
Notice that this *does* work with ConfigParser but you can't express
'else' conditions easily. But this is not a great deal, I can accomodate not
having elses.
Maybe the expression can be located in a specific variable for readability:
"""
[setup]
name = foo
conditional-sections = one, two
[one]
condition: platform="linux" and python >= "2.5"
require: lxml
[two]
condition: platform="win32" and python >= "2.5"
require: docutils
"""
This would be more powerfull since each section could define any metadata,
under some conditions.
I would be ok with that shape, even if I do find this more readable:
"""
[setup]
name = foo
{$ if platform="linux" and python >= "2.5": $}
require: lxml
{$ :endif $}
{$ platform="win32" and python >= "2.5": $)
require: docutils
{$ :endif $}
"""
In any case, the restrictions to what variables the expressions can
work with would stay the same.
>
> --
> Greg
> ___
> Distutils-SIG maillist - distutils-...@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
--
Tarek Ziadé | http://ziade.org | オープンソースの岩！
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Wed, 09 Sep 2009 11:31:42 +1200, Greg Ewing wrote: > Maybe the conditions could be expressed in the > section headers? > > [requires platform="linux"] > ... > > [requires platform="win32"]: > ... > > Then it's not so much if-then-else logic as just > tagging parts of the file with conditions under > which they apply. +1 or just.. [requires linux2] ... [requires win32]: ... [requires kde] ... [requires gnome] ... [requires darwin] ... David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Tarek Ziadé wrote: In that case, if we want to keep a configparser-compatible file, we need to find another way to express these if/else parts, which will probably lead to a complex, non natural syntax. Maybe the conditions could be expressed in the section headers? [requires platform="linux"] ... [requires platform="win32"]: ... Then it's not so much if-then-else logic as just tagging parts of the file with conditions under which they apply. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, 8 Sep 2009 10:26:19 +0200, Tarek Ziadé wrote: > I am restricting the template language to two expressions: "if" and "else" > > The values you can work with in the "if" and "else" section will be > restricted to : > > - the python version (string) > - the os.name (string) > - the os.platform (string) > - an extra function called "long_description", to be able to point a > file for the long description field > > and nothing else. > > How anyone could abuse of that kind of expressions ? What about nested if statements? Real world example, if os=="linux2" and window_manager=="kde": .. elif os=="linux2" and window_manager=="gnome": .. How would that be handled? David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, 8 Sep 2009 14:20:30 +0200, Tarek Ziadé
wrote:
> The practice in the community is to create the long_description field
> using a separate reStructuredText file
> and reaching it in setup.py like this for example:
>
> long_description = open('README.txt').read()
>
> Having a callable that provides this feature in the template allows
> writing:
>
> """
> [setup.cfg]
>
> long_description: {$ long_description('README.txt') $}
> """
If the config file is actually a code file... (mixing config
with code)... what has been accomplished?
I was always led to believe that mixing static data with code was
bad programming practice. Have configuration files for configuration
and program files for programs.
Why have a static data file?
Why not go back to setup.py which was mixed data/code?
David
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, Sep 08, 2009 at 02:53:49PM +0200, Tarek Ziadé wrote:
> On Tue, Sep 8, 2009 at 2:32 PM, Eric Smith wrote:
> > Tarek Ziadé wrote:
> >>
> >> On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers
> >> wrote:
> >>>
> >>> Tarek Ziadé wrote:
>
> - an extra function called "long_description", to be able to point a
> file for the long description field
> >>>
> >>> I can't comment on the others, but this is unnecessary. Why do you need
> >>> more
> >>> than:
> >>>
> >>> long_decription="some lump of text"
> >>>
> >>> or
> >>>
> >>> long_description_path ="path/relative/to/directory/containing/setup.py"
> >>>
> >>> ...with it being an error for both to be specified?
> >>>
> >>> cheers,
> >>>
> >>
> >> The practice in the community is to create the long_description field
> >> using a separate reStructuredText file
> >> and reaching it in setup.py like this for example:
> >>
> >> long_description = open('README.txt').read()
> >>
> >> Having a callable that provides this feature in the template allows
> >> writing:
> >>
> >> """
> >> [setup.cfg]
> >>
> >> long_description: {$ long_description('README.txt') $}
> >> """
> >>
> >> Thus avoiding to write anything in setup.py for that particular case.
> >> the callable could be called "read_file()" maybe, so it's clearer.
> >>
> >> long_description_path can't be added in the final PKG-INFO because
> >> we want a self-contained metadata static file that doesn't require an
> >> extra resource (like an external file)
> >>
> >> Whereas having a file path in setup.cfg.in is acceptable, as long as
> >> the resulting setup.cfg
> >> contains everything needed to get the metadata of the package without
> >> further depenencies.
> >>
> >> so if by the time setup.cfg.in is compiled, the path cannot be found,
> >> the field will have its value set to "UNKOWN" in setup.cfg
> >
> > Which all points out that it's setup.cfg that is the static metadata, and
> > that you can generate it any way you want. If you want to use m4, use m4. If
> > you want to use python, use python. If you want to have some makefile driven
> > approach, or use autoconf, or whatever, do that.
> >
> > setup.cfg should be entirely static except for some simple if-then-else
> > logic involving versions, as Tarek has described earlier. That is, it should
> > only contain logic that needs to be decided on the platform where the
> > installation is taking place. This is basically what RPM provides.
> >
> > Any other logic, in particular logic used solely for building setup.cfg,
> > should be outside the scope of this system, because you can use any tool at
> > all for it.
> >
>
> So you are suggesting that setup.cfg includes the "if/else" logic
> instead of having it
> in a "setup.cfg.in" file ?
I'm more in favour of your original idea to have setup.cfg being
completely static and have the if/else logic in setup.cfg.in.
Regards
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, Sep 8, 2009 at 2:32 PM, Eric Smith wrote:
> Tarek Ziadé wrote:
>>
>> On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers
>> wrote:
>>>
>>> Tarek Ziadé wrote:
- an extra function called "long_description", to be able to point a
file for the long description field
>>>
>>> I can't comment on the others, but this is unnecessary. Why do you need
>>> more
>>> than:
>>>
>>> long_decription="some lump of text"
>>>
>>> or
>>>
>>> long_description_path ="path/relative/to/directory/containing/setup.py"
>>>
>>> ...with it being an error for both to be specified?
>>>
>>> cheers,
>>>
>>
>> The practice in the community is to create the long_description field
>> using a separate reStructuredText file
>> and reaching it in setup.py like this for example:
>>
>> long_description = open('README.txt').read()
>>
>> Having a callable that provides this feature in the template allows
>> writing:
>>
>> """
>> [setup.cfg]
>>
>> long_description: {$ long_description('README.txt') $}
>> """
>>
>> Thus avoiding to write anything in setup.py for that particular case.
>> the callable could be called "read_file()" maybe, so it's clearer.
>>
>> long_description_path can't be added in the final PKG-INFO because
>> we want a self-contained metadata static file that doesn't require an
>> extra resource (like an external file)
>>
>> Whereas having a file path in setup.cfg.in is acceptable, as long as
>> the resulting setup.cfg
>> contains everything needed to get the metadata of the package without
>> further depenencies.
>>
>> so if by the time setup.cfg.in is compiled, the path cannot be found,
>> the field will have its value set to "UNKOWN" in setup.cfg
>
> Which all points out that it's setup.cfg that is the static metadata, and
> that you can generate it any way you want. If you want to use m4, use m4. If
> you want to use python, use python. If you want to have some makefile driven
> approach, or use autoconf, or whatever, do that.
>
> setup.cfg should be entirely static except for some simple if-then-else
> logic involving versions, as Tarek has described earlier. That is, it should
> only contain logic that needs to be decided on the platform where the
> installation is taking place. This is basically what RPM provides.
>
> Any other logic, in particular logic used solely for building setup.cfg,
> should be outside the scope of this system, because you can use any tool at
> all for it.
>
So you are suggesting that setup.cfg includes the "if/else" logic
instead of having it
in a "setup.cfg.in" file ?
In that case, if we want to keep a configparser-compatible file, we
need to find another
way to express these if/else parts, which will probably lead to a
complex, non natural
syntax.
Having a "setup.cfg.in" file with if/else logic in it, to build the
setup.cfg independanlty
from the package code, using a function provided by python's stdlib, allows
us to have a simple syntax.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org | オープンソースの岩！
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Tarek Ziadé wrote:
On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers wrote:
Tarek Ziadé wrote:
- an extra function called "long_description", to be able to point a
file for the long description field
I can't comment on the others, but this is unnecessary. Why do you need more
than:
long_decription="some lump of text"
or
long_description_path ="path/relative/to/directory/containing/setup.py"
...with it being an error for both to be specified?
cheers,
The practice in the community is to create the long_description field
using a separate reStructuredText file
and reaching it in setup.py like this for example:
long_description = open('README.txt').read()
Having a callable that provides this feature in the template allows writing:
"""
[setup.cfg]
long_description: {$ long_description('README.txt') $}
"""
Thus avoiding to write anything in setup.py for that particular case.
the callable could be called "read_file()" maybe, so it's clearer.
long_description_path can't be added in the final PKG-INFO because
we want a self-contained metadata static file that doesn't require an
extra resource (like an external file)
Whereas having a file path in setup.cfg.in is acceptable, as long as
the resulting setup.cfg
contains everything needed to get the metadata of the package without
further depenencies.
so if by the time setup.cfg.in is compiled, the path cannot be found,
the field will have its value set to "UNKOWN" in setup.cfg
Which all points out that it's setup.cfg that is the static metadata,
and that you can generate it any way you want. If you want to use m4,
use m4. If you want to use python, use python. If you want to have some
makefile driven approach, or use autoconf, or whatever, do that.
setup.cfg should be entirely static except for some simple if-then-else
logic involving versions, as Tarek has described earlier. That is, it
should only contain logic that needs to be decided on the platform where
the installation is taking place. This is basically what RPM provides.
Any other logic, in particular logic used solely for building setup.cfg,
should be outside the scope of this system, because you can use any
tool at all for it.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
2009/9/8 Chris Withers : >> I suggested that a "requires" section could easily do this, something >> along the lines of: >> >> [Requires] >> stdlib=sqlite>=1.5 > > Tarek, How are requirements spelled for packages in your current setup.cfg? Sorry, that's another problem we are dealing with here e.g. How *one* requirement is defined. The .cfg file is just a format that holds values, like you would express them in command line or in arguments. The "How are requirements spelled" part is the changes we will add in PEP 345. The templating part is just here to make these requirements (or anything else) vary, depending on a few environment values, so it can be read without installing the distribution, with a vanilla Python. Please stop cross-posting in other mailing-lists it makes the discussions confusing. there are two discussions, to be talked in distutils-SIG: 1/ static metadata using a setup.cfg.in (the current one) 2/ changes that will occur in PEP 345, to include requirement definitions Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースの岩！ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, Sep 8, 2009 at 10:29 AM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> - an extra function called "long_description", to be able to point a
>> file for the long description field
>
> I can't comment on the others, but this is unnecessary. Why do you need more
> than:
>
> long_decription="some lump of text"
>
> or
>
> long_description_path ="path/relative/to/directory/containing/setup.py"
>
> ...with it being an error for both to be specified?
>
> cheers,
>
The practice in the community is to create the long_description field
using a separate reStructuredText file
and reaching it in setup.py like this for example:
long_description = open('README.txt').read()
Having a callable that provides this feature in the template allows writing:
"""
[setup.cfg]
long_description: {$ long_description('README.txt') $}
"""
Thus avoiding to write anything in setup.py for that particular case.
the callable could be called "read_file()" maybe, so it's clearer.
long_description_path can't be added in the final PKG-INFO because
we want a self-contained metadata static file that doesn't require an
extra resource (like an external file)
Whereas having a file path in setup.cfg.in is acceptable, as long as
the resulting setup.cfg
contains everything needed to get the metadata of the package without
further depenencies.
so if by the time setup.cfg.in is compiled, the path cannot be found,
the field will have its value set to "UNKOWN" in setup.cfg
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
David Lyon wrote: On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers wrote: If Python had a packaging system *and* used it for the standard library, then things like this wouldn't be a problem... The setup.cfg could just say "requires sqlite greater than version x.y.z", and if it was in the standard library, it would be used unless a newer version was needed. +1 Actually, this was already discussed on this mailing list. Yeah, I know, but I had memories of it be poo-poo'ed on Python-Dev... (CC'ing so they can tell me I'm wrong ;-) ) I suggested that a "requires" section could easily do this, something along the lines of: [Requires] stdlib=sqlite>=1.5 Tarek, How are requirements spelled for packages in your current setup.cfg? I really don't see why anything should be different for standard library packages (ie: the stdlib= prefix in David's example). Python distributions should just declare all the versions they come with in the same way that whatever-is-being-built by Tarek can introspect in the same way as any other package... So the concept of having an if/else test for this is superfluous. Right. It would also mean it would be possible to release bug fix versions of the standard library packages without having to roll a whole python release. +1 ...which in turn would mean that the standard library is no longer a place where packages go to die... Better yet, since "python" should be a package as far as the packaging system is concerned, library versions can just say what versions of python they work with. +1 - good idea ...and for me, the "python" package should be just another package in the distributions dance, called "python" ;-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers wrote: > > If Python had a packaging system *and* used it for the standard library, > then things like this wouldn't be a problem... > The setup.cfg could just say "requires sqlite greater than version > x.y.z", and if it was in the standard library, it would be used unless a > newer version was needed. +1 Actually, this was already discussed on this mailing list. I suggested that a "requires" section could easily do this, something along the lines of: [Requires] stdlib=sqlite>=1.5 So the concept of having an if/else test for this is superfluous. > It would also mean it would be possible to > release bug fix versions of the standard library packages without having > to roll a whole python release. +1 > Better yet, since "python" should be a package as far as the packaging > system is concerned, library versions can just say what versions of > python they work with. +1 - good idea David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, Sep 07, 2009 at 05:41:40PM +0200, Tarek Ziadé wrote: > The template engine will be restricted to "if", and the expression > will be able to ^may only 3 values: > > - the python version > - sys.platform > - os.name The members of the structure/named-tuple returned os.uname() too please, otherwise I won't have enough information. On Windows I guess the service pack versions etc are the equivalent. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On 8 Sep, 2009, at 10:18, Chris Withers wrote: Ronald Oussoren wrote: I have a number of packages where the only logic on setup.py is set flags based on the python version or OS. Examples: * depend on pysqlite in old versions of python where sqlite wasn't in the stdlib If Python had a packaging system *and* used it for the standard library, then things like this wouldn't be a problem... The setup.cfg could just say "requires sqlite greater than version x.y.z", and if it was in the standard library, it would be used unless a newer version was needed. It would also mean it would be possible to release bug fix versions of the standard library packages without having to roll a whole python release. Yes, it is sad that only wsgiref is included in the stdlib with an egg- info file. Better yet, since "python" should be a package as far as the packaging system is concerned, library versions can just say what versions of python they work with. I like this idea, adding this to distutils and setuptools should be easy enough as well. It would be nice if those could be expressed in a setup.cfg(.in) file, because that way to can introspect these packages without having to execute a setup.py file. No, you just have to execute setup.cfg instead :-( Yes, but I'd be much happier about exanding a template than executing some arbitrary python code. You obviously have to trust the author when you actually install and use the package, but it would be nice if one could extract useful information from a package before doing that. For me, setup.cfg should contain static stuff like name, description, url and dependencies. Anything else that varies like this can and should be in setup.py. We already have a fantastic scripting language, why coem up with another one? Because static stuff is not always completely static. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Tarek Ziadé wrote: - an extra function called "long_description", to be able to point a file for the long description field I can't comment on the others, but this is unnecessary. Why do you need more than: long_decription="some lump of text" or long_description_path ="path/relative/to/directory/containing/setup.py" ...with it being an error for both to be specified? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
2009/9/8 Chris Withers : >> I agree that the file shouldn't be too dynamic, we don't need a full >> programming language in setup.cfg because we already have setup.py files. > > It's an extremely slippery slope, as soon as there's any possibility for > weirdness some inexperienced developer will jump at the chance to abuse it > to its fullest extent :-( I am restricting the template language to two expressions: "if" and "else" The values you can work with in the "if" and "else" section will be restricted to : - the python version (string) - the os.name (string) - the os.platform (string) - an extra function called "long_description", to be able to point a file for the long description field and nothing else. How anyone could abuse of that kind of expressions ? Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースの岩！ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Ronald Oussoren wrote: I have a number of packages where the only logic on setup.py is set flags based on the python version or OS. Examples: * depend on pysqlite in old versions of python where sqlite wasn't in the stdlib If Python had a packaging system *and* used it for the standard library, then things like this wouldn't be a problem... The setup.cfg could just say "requires sqlite greater than version x.y.z", and if it was in the standard library, it would be used unless a newer version was needed. It would also mean it would be possible to release bug fix versions of the standard library packages without having to roll a whole python release. Better yet, since "python" should be a package as far as the packaging system is concerned, library versions can just say what versions of python they work with. It would be nice if those could be expressed in a setup.cfg(.in) file, because that way to can introspect these packages without having to execute a setup.py file. No, you just have to execute setup.cfg instead :-( For me, setup.cfg should contain static stuff like name, description, url and dependencies. Anything else that varies like this can and should be in setup.py. We already have a fantastic scripting language, why coem up with another one? I agree that the file shouldn't be too dynamic, we don't need a full programming language in setup.cfg because we already have setup.py files. It's an extremely slippery slope, as soon as there's any possibility for weirdness some inexperienced developer will jump at the chance to abuse it to its fullest extent :-( cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On 7 Sep, 2009, at 14:15, Chris Withers wrote: I'd prefer setup.cfg to be totally static. If there are complicated if/then/else's needed, they should be in setup.py. I have a number of packages where the only logic on setup.py is set flags based on the python version or OS. Examples: * depend on pysqlite in old versions of python where sqlite wasn't in the stdlib * select different compiler flags based for Linux vs. Windows for a C extension It would be nice if those could be expressed in a setup.cfg(.in) file, because that way to can introspect these packages without having to execute a setup.py file. As soon as this file becomes dynamic, we're back in the situation where you can't tell what a package requires without installing it, which is something I'd really like to not have to do. I agree that the file shouldn't be too dynamic, we don't need a full programming language in setup.cfg because we already have setup.py files. The proof of concept already severely limits what constructs the template can use, and those should both be enough for most python packages and simple enough to allow easy introspection. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, 08 Sep 2009 11:18:09 +0900, David Cournapeau wrote: >> I can see your intentions here are good. But what you are suggesting is >> just overly complicated for what is required. There's no need for a >> templating engine, in this part of distutils. >> > > Compared to other parts of distutils, that's very simple, and actually > useful and well established practice. Perphaps. But why make the simplest part as complex as the most complex. > having if/then don't make distutils more complicated. There's no debate about that. The need for an if/else is clear. What is up for discussion is having it in python code or template code. > The point of those > 'dynamic' features in the static metadata is that a vast majority of > projects can be *fully* described without a setup.py file - without it, > very few packages would fall in that category. Too complex a statement for me to comment on... > Once you can describe a non trivial subset of all python packages with a > static metadata file, it means you can use it without using distutils > itself, which is a very big plus. Yes. That's why I have been pushing and pushing for this... > Actually, almost every one I have ever seen does. Which installation > system does not use a templating engine of some sort ? That's a very > common practice. I originally said, templating isn't required for for a "install-my-hellow world". Innosetup, NSIS under windows are examples of install systems that don't require any templating to make a simple installation file. Regards David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
David Lyon wrote: > > I can see your intentions here are good. But what you are suggesting is > just overly complicated for what is required. There's no need for a > templating engine, in this part of distutils. > Compared to other parts of distutils, that's very simple, and actually useful and well established practice. > Yes, introducing a template engine might be good for multi-platform > output. > > But the setup.py and setup.cfg and [setup] sections must be readily > understood by the complete novice. That's the point that you don't > seem to understand yet. Stop making it non-obvious. > having if/then don't make distutils more complicated. The point of those 'dynamic' features in the static metadata is that a vast majority of projects can be *fully* described without a setup.py file - without it, very few packages would fall in that category. Once you can describe a non trivial subset of all python packages with a static metadata file, it means you can use it without using distutils itself, which is a very big plus. > No installation system I have ever heard of makes it mandatory > to understand a template system to be able to write your "hello > world - I'm installed" script.. > Actually, almost every one I have ever seen does. Which installation system does not use a templating engine of some sort ? That's a very common practice. cheers, David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Chris Withers wrote: > Seems like a bad goal to me. > > I'd prefer setup.cfg to be totally static. If there are complicated > if/then/else's needed, they should be in setup.py. > > As soon as this file becomes dynamic, we're back in the situation > where you can't tell what a package requires without installing it, > which is something I'd really like to not have to do. I don't see how you would reach that conclusion - rpm spec files have basic if/then/else, and they certainly don't have the problem you mention. Cabal files in haskell have this construction as well. Both work very well. cheers, David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, 7 Sep 2009 17:41:40 +0200, Tarek Ziadé wrote: >> I'd prefer setup.cfg to be totally static. If there are complicated >> if/then/else's needed, they should be in setup.py. +1 > The template engine will be restricted to "if", and the expression > will be able to ^may only 3 values: > > - the python version > - sys.platform > - os.name That's very, very hard It makes it harder for the developer because they must learn yet another templating system. Add half a days work to every developer. >> As soon as this file becomes dynamic, we're back in the situation where >> you >> can't tell what a package requires without installing it, which is >> something >> I'd really like to not have to do. +1 > setup.cfg stays static. We're talking about the ability to add a > setup.cfg.in file, > that generates the setup.cfg file ***without having to run any third > party code***. > > So again, this will not require any installation to run since transforming > a "setup.cfg.in" into a "setup.cfg" will just require a vanilla Python It's still just overly complicated.. > to synthetize = > > if exists(setup.cfg.in): > setup.cfg = distutils.some_func(setup.cfg.in) > else: > nothing > > That's the whole point ! ;) Point is to introduce distutils? haha - why not just use setuptools? > It means that people will be able to read the .cfg file, and if needed > to rebuild for their platform > without any installation required. > > Eventually, PyPI can provide both (.cfg and .cfg.in) as metadata that a > tool can > grab to see what's required for installation, *without installing the > package* I can see your intentions here are good. But what you are suggesting is just overly complicated for what is required. There's no need for a templating engine, in this part of distutils. Yes, introducing a template engine might be good for multi-platform output. But the setup.py and setup.cfg and [setup] sections must be readily understood by the complete novice. That's the point that you don't seem to understand yet. Stop making it non-obvious. No installation system I have ever heard of makes it mandatory to understand a template system to be able to write your "hello world - I'm installed" script.. Especially when the alternative is just "if os.name == "win32:" .. I see nothing wrong with such a simple piece of python code... Regards David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, Sep 7, 2009 at 2:15 PM, Chris Withers wrote: >> For example being able to express: >> >> "if the target python is version 2.6 the dependencies are ..." >> >> The goal is to be able to run that part on a vanilla Python. without >> having to rely on the distribution's setup.py > > Seems like a bad goal to me. Why ? > > I'd prefer setup.cfg to be totally static. If there are complicated > if/then/else's needed, they should be in setup.py. The template engine will be restricted to "if", and the expression will be able to ^may only 3 values: - the python version - sys.platform - os.name > > As soon as this file becomes dynamic, we're back in the situation where you > can't tell what a package requires without installing it, which is something > I'd really like to not have to do. > setup.cfg stays static. We're talking about the ability to add a setup.cfg.in file, that generates the setup.cfg file ***without having to run any third party code***. So again, this will not require any installation to run since transforming a "setup.cfg.in" into a "setup.cfg" will just require a vanilla Python to synthetize = if exists(setup.cfg.in): setup.cfg = distutils.some_func(setup.cfg.in) else: nothing That's the whole point ! ;) It means that people will be able to read the .cfg file, and if needed to rebuild for their platform without any installation required. Eventually, PyPI can provide both (.cfg and .cfg.in) as metadata that a tool can grab to see what's required for installation, *without installing the package* Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースの岩！ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Tarek Ziadé wrote: - I've never had to use anything that would require the kind of templating being discussed here, so please make setup.cfg "just work" if setup.cfg.in isn't there. That's the case Yay :-) - I think any kind of templating language is *way to heavyweight*. If you need anything more than simple string substitution, then the code should be in setup.py Well, the point is to be able to define sections in a static file that will be used without having to execute any code in the distribution. For example being able to express: "if the target python is version 2.6 the dependencies are ..." The goal is to be able to run that part on a vanilla Python. without having to rely on the distribution's setup.py Seems like a bad goal to me. I'd prefer setup.cfg to be totally static. If there are complicated if/then/else's needed, they should be in setup.py. As soon as this file becomes dynamic, we're back in the situation where you can't tell what a package requires without installing it, which is something I'd really like to not have to do. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, Aug 31, 2009 at 1:55 PM, Chris Withers wrote: > Tarek Ziadé wrote: >> >> Here's a demo of what I was thinking of adding in Distutils: >> >> http://bitbucket.org/tarek/staticmetadata/ >> >> It uses Mako just for the proof of concept, README.txt explains how it >> works >> >> Let me know how this fits your needs, > > A couple of things: > > - I've never had to use anything that would require the kind of templating > being discussed here, so please make setup.cfg "just work" if setup.cfg.in > isn't there. That's the case > > - I think any kind of templating language is *way to heavyweight*. If you > need anything more than simple string substitution, then the code should be > in setup.py Well, the point is to be able to define sections in a static file that will be used without having to execute any code in the distribution. For example being able to express: "if the target python is version 2.6 the dependencies are ..." The goal is to be able to run that part on a vanilla Python. without having to rely on the distribution's setup.py Cheers Tarek > > cheers, > > Chris > > -- > Simplistix - Content Management, Batch Processing & Python Consulting > - http://www.simplistix.co.uk > -- Tarek Ziadé | http://ziade.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Tarek Ziadé wrote: Here's a demo of what I was thinking of adding in Distutils: http://bitbucket.org/tarek/staticmetadata/ It uses Mako just for the proof of concept, README.txt explains how it works Let me know how this fits your needs, A couple of things: - I've never had to use anything that would require the kind of templating being discussed here, so please make setup.cfg "just work" if setup.cfg.in isn't there. - I think any kind of templating language is *way to heavyweight*. If you need anything more than simple string substitution, then the code should be in setup.py cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, Aug 18, 2009 at 6:32 PM, Tarek Ziadé wrote: > On Tue, Aug 18, 2009 at 1:26 PM, Eric Smith wrote: >> David Lyon wrote: >>> >>> That's why we need to keep it simple. Handle 85% of use cases with >>> config and the other 15% with the ability to use (python) code. >> >> The part that needs to by "code-like" is only the stuff that's needed when >> the config file is used by an installer, and is known only to the target >> system. Remember one of the points of having a static file (as we discussed >> at the language summit) is so that installers can install a "module >> distribution" (distutils term) without executing any python code. >> >> So version dependencies might need to be code-like, per-python-version >> dependencies might also need to be. But the long description doesn't. If you >> want it to be read from some other file, use a script (possibly in a >> makefile) that generates the config file from various pieces. >> >> I think these things that need to be code-like are things that depend on the >> target system and can't be known until an actual installation takes place. >> The rest of it can be truly static. I think this list of code-like things >> can and should be enumerated, and should be very small. >> >> Ideally, they'd be translatable into the same sorts of expressions that are >> understood by rpm and deb (and other) installers, but that's a tall order. > > What about a fully static setup.cfg file, and a template file called > setup.cfg.in, > working like MANIFEST and MANIFEST.in Here's a demo of what I was thinking of adding in Distutils: http://bitbucket.org/tarek/staticmetadata/ It uses Mako just for the proof of concept, README.txt explains how it works Let me know how this fits your needs, Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, Aug 25, 2009 at 1:13 AM, David Lyon wrote: > On Mon, 24 Aug 2009 17:58:47 +0200, Tarek Ziadé > wrote: >> btw, I have a working prototype for the setup.cfg.in template file, >> I'll push here when I get home tonite, for feedback > > This seems somewhat unfair that I cannot participate in the > development of this. > > I've asked you onlist and offlist how I go about this but I > never get any answer. > > Now you claim to have "closed" source on this... > > Not nice - Tarek... > I've always answered your private mails and IMs, that's not very rewarding :) I have done a prototype (=not closed, not finished) right after the discussion, in the train back home, and I got your private mail *after* that telling me that you wanted to participate. I was waiting to push it on a public repo so people here (including you) could participate in it if they wanted. And I was going to answer to your mail at that moment. I am sorry if you feel frustrated somehow, but this was not my intent. I guess the best way to exchange is to stick in this mailing list and in the code that get published. Cheers Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, 24 Aug 2009 17:58:47 +0200, Tarek Ziadé wrote: > btw, I have a working prototype for the setup.cfg.in template file, > I'll push here when I get home tonite, for feedback This seems somewhat unfair that I cannot participate in the development of this. I've asked you onlist and offlist how I go about this but I never get any answer. Now you claim to have "closed" source on this... Not nice - Tarek... ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, Aug 24, 2009 at 6:05 PM, Chris Withers wrote: > Tarek Ziadé wrote: >> >> If we change the name, I would rather call it [metadata] >> which is more explicit than [setup] > > Not really... metadata is a generic, meaningless word. I disagree. We are talking about the fields that describes... 'Metadata for Python Software Packages' (see PEP 241 + PEP 314) So I don't find the word "metadata" meaningless. Whereas "setup" is meaningless to me in this context, especially iff we are already located in a file called setup.cfg: it doesn't add any useful information, just redundancy. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Tarek Ziadé wrote: If we change the name, I would rather call it [metadata] which is more explicit than [setup] Not really... metadata is a generic, meaningless word. We're talking about setup metadata, so I think [setup] makes more sense. I think the parallels with setup.py and setup.cfg are also better for discoverability... btw, I have a working prototype for the setup.cfg.in template file, I'll push here when I get home tonite, for feedback I missed the thread on this... Why is it needed? I generally hate the idea of having a .in file for a .cfg file. It's a sign that the .cfg fiel is being used incorrectly... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
2009/8/24 Chris Withers : > David Lyon wrote: >> >> On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziadé >> wrote: >>> >>> We can use the [global] section of the setup.cfg file to describe them. >> >> My suggestion is [setup] because it directly corresponds to the setup() >> function. I know it is a triplication of the name (setup.cfg, setup() >> and then [setup]) but it's much more consistent and will be easier to >> find for new users. > > +1 If we change the name, I would rather call it [metadata] which is more explicit than [setup] : it's a section containing the metadata of the distribution. btw, I have a working prototype for the setup.cfg.in template file, I'll push here when I get home tonite, for feedback ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
P.J. Eby wrote: In which case, why not simply have a "configure"-like command that generates a fixed set of static metadata? Or better yet, make it "configure.py" or something like that. Since it is not the old setup.py, it does not have to offer the same command line interface or be backward compatible with existing code. minus lots on allowing it to be anything other than an extremely constrained domain specific language... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
David Lyon wrote: On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziadé wrote: We can use the [global] section of the setup.cfg file to describe them. My suggestion is [setup] because it directly corresponds to the setup() function. I know it is a triplication of the name (setup.cfg, setup() and then [setup]) but it's much more consistent and will be easier to find for new users. +1 Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Jeff Rush wrote: The long_description field is also a reStructuredText field and as such, Indeed, for this I'd prefer a long_description_path to a file containing the long description... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, Aug 18, 2009 at 11:47 AM, Ben Finney wrote:
> Jeff Rush writes:
>
>> The long_description field is also a reStructuredText field and as
>> such, for the developer to preview it during its composure, it needs
>> to be left-aligned. While a developer -could- cut/paste it into a
>> separate text file each time he wants to test preview it, that would
>> be annoying.
Right, following my template proposal (setup.cfg.in), in your case,
the template engine
would require a feature to be able to inject a file in setup.cfg
>
> I get my ‘description’ and ‘long_description’ field not directly from a
> text file, but from the package docstring. Following the usual docstring
> interpretation conventions as per PEP 257, I trim all common leading
> indentation from non-blank lines:
>
> import textwrap
> import foopackage
>
> short_description, long_description = (
> textwrap.dedent(d).strip()
> for d in main_module.__doc__.split('\n\n', 1))
>
As said earlier in this thread, these could be pre-generated in you
release process,
in a static file that can be used by setup.cfg.in without requiring
your code to be shipped
to be able to get static metadata.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, Aug 18, 2009 at 1:26 PM, Eric Smith wrote: > David Lyon wrote: >> >> That's why we need to keep it simple. Handle 85% of use cases with >> config and the other 15% with the ability to use (python) code. > > The part that needs to by "code-like" is only the stuff that's needed when > the config file is used by an installer, and is known only to the target > system. Remember one of the points of having a static file (as we discussed > at the language summit) is so that installers can install a "module > distribution" (distutils term) without executing any python code. > > So version dependencies might need to be code-like, per-python-version > dependencies might also need to be. But the long description doesn't. If you > want it to be read from some other file, use a script (possibly in a > makefile) that generates the config file from various pieces. > > I think these things that need to be code-like are things that depend on the > target system and can't be known until an actual installation takes place. > The rest of it can be truly static. I think this list of code-like things > can and should be enumerated, and should be very small. > > Ideally, they'd be translatable into the same sorts of expressions that are > understood by rpm and deb (and other) installers, but that's a tall order. What about a fully static setup.cfg file, and a template file called setup.cfg.in, working like MANIFEST and MANIFEST.in A - From the developer PoV: 1. the developer doesn't have metadata that depend on the target system, he provides a static setup.cfg 2. the developer does have metadata that depend on the target system, he provides a setup.cfg.in that can be processed by distutils to generate a setup.cfg file The setup.cfg.in file would then have expressions ala automake, that could be used to generate the setup.cfg. When distributions are made, a default setup.cfg is generated in case a setup.cfg.in is found, and it's updated when installed on the target system. The execution environment will contain a restricted list of functions to query the environment, provided by distutils, to make conditional statements in the file. - sys.platform - os.name - python version - others ? The advantages of a ".in" file is that we don't have to stick with the ConfigParser format and enjoy conditional sections. Plus, it's a hint to know that the dsitribution installation differs depending on the patform. B - From the OS packager PoV: 1. he sees a setup.cfg.in file, he knows that the distribution has os specific metadata. he tweaks the setup.cfg.in file and re-generate the setup.cfg. 2. he uses setup.cfg when provided alone C - From PyPI user PoV Both setup.cfg and setup.cfg.in files are uploaded besides the archive, allowing people to get the static metadata for their platform without having to dowload and install the whole distribution. This will work as long as the expressions are restricted to something that can be run on a vanilla Python. For the template file syntax, a simple "if" would be sufficient to allow conditional parts in the template Tarek -- Tarek Ziadé | http://ziade.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
At 08:08 AM 8/18/2009 +0100, Floris Bruynooghe wrote: The benefit is that you allow developers to specify anything possible, but still allow package management systems to analyse the dependencies and modules etc from static data. They will recognise that something is conditional but are free to do with that knowledge they want. In which case, why not simply have a "configure"-like command that generates a fixed set of static metadata? Or better yet, make it "configure.py" or something like that. Since it is not the old setup.py, it does not have to offer the same command line interface or be backward compatible with existing code. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
David Lyon wrote: That's why we need to keep it simple. Handle 85% of use cases with config and the other 15% with the ability to use (python) code. The part that needs to by "code-like" is only the stuff that's needed when the config file is used by an installer, and is known only to the target system. Remember one of the points of having a static file (as we discussed at the language summit) is so that installers can install a "module distribution" (distutils term) without executing any python code. So version dependencies might need to be code-like, per-python-version dependencies might also need to be. But the long description doesn't. If you want it to be read from some other file, use a script (possibly in a makefile) that generates the config file from various pieces. I think these things that need to be code-like are things that depend on the target system and can't be known until an actual installation takes place. The rest of it can be truly static. I think this list of code-like things can and should be enumerated, and should be very small. Ideally, they'd be translatable into the same sorts of expressions that are understood by rpm and deb (and other) installers, but that's a tall order. Eric. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, 18 Aug 2009 03:03:57 -0500, Jeff Rush wrote: > David Lyon wrote: >>> the long_description field is expressed as a multi-line field following >>> the config parser convention so no problem for it (see my example) > > The long_description field is also a reStructuredText field and as such, > for the developer to preview it during its composure, it needs to be > left-aligned. While a developer -could- cut/paste it into a separate > text file each time he wants to test preview it, that would be annoying. ok - well not much can be done to eliminate the classic ID10t error.. and wth is that guy doing? editing the file without emacs... serves him right (doesn't emacs fix everything?) :-) Normal users would edit the text imho with a text boxt. The congigparser takes care of adjusting everything up. I'm operating on the assumption that there's a "util" to edit the file somewhere in distutils.. > Many of these ideas have already been expressed in a buildout.cfg file > that also uses ConfigParser. Look there for ideas on how to do lists, > order things, substitute fields. If I get time... I'm just bashing this stuff out as I go along.. and there's probably some way of improving most everything I suggest. I'm not an 'old' python hack.. I'm still learning.. > However if you put too much expressive > power into the metadata file, you make it hard to programatically reason > about what is means, which is the whole point of having a static > metadata file. That's why we need to keep it simple. Handle 85% of use cases with config and the other 15% with the ability to use (python) code. David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Jeff Rush writes:
> The long_description field is also a reStructuredText field and as
> such, for the developer to preview it during its composure, it needs
> to be left-aligned. While a developer -could- cut/paste it into a
> separate text file each time he wants to test preview it, that would
> be annoying.
I get my ‘description’ and ‘long_description’ field not directly from a
text file, but from the package docstring. Following the usual docstring
interpretation conventions as per PEP 257, I trim all common leading
indentation from non-blank lines:
import textwrap
import foopackage
short_description, long_description = (
textwrap.dedent(d).strip()
for d in main_module.__doc__.split('\n\n', 1))
If we want to allow a multi-line option value in a configuration file,
we could define the interpretation of that value by the same or similar
convention.
--
\ “Well, my brother says Hello. So, hooray for speech therapy.” |
`\ —Emo Philips |
_o__) |
Ben Finney
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
David Lyon wrote: > On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziadé > wrote: >> the long_description field is expressed as a multi-line field following >> the config parser convention so no problem for it (see my example) The long_description field is also a reStructuredText field and as such, for the developer to preview it during its composure, it needs to be left-aligned. While a developer -could- cut/paste it into a separate text file each time he wants to test preview it, that would be annoying. >> Although there's another change we need to apply and decide : being >> able to express a >> list of values, for fields like "keywords" or "classifiers". > > [Files] > file1 = abc.txt > file2 = def.txt > > You can get all the keys in "[Files]" in a list in the configparser > class. Many of these ideas have already been expressed in a buildout.cfg file that also uses ConfigParser. Look there for ideas on how to do lists, order things, substitute fields. However if you put too much expressive power into the metadata file, you make it hard to programatically reason about what is means, which is the whole point of having a static metadata file. If you put too little, people will stick with setup.py. -Jeff ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On 18 Aug, 2009, at 9:08, Floris Bruynooghe wrote:
On Tue, Aug 18, 2009 at 05:11:28AM +0300, Alex Grönholm wrote:
How would you declare dependencies? Remember that the list of
dependencies depends on at least two variables: Python version and
platform.
Many more, defining a known list of variables to be used to define
dependencies is not going to be enough. Maybe there should be a way
of having general purpose named conditionals and implement a mapping
so that setup.py can define boolean functions for each named
conditional. This can then be used for modules etc too instead of
just dependencies.
The benefit is that you allow developers to specify anything possible,
but still allow package management systems to analyse the
dependencies and modules etc from static data. They will recognise
that something is conditional but are free to do with that knowledge
they want.
Expressiong conditionals in an elegant-ConfigParser-compatible way
might be tricky.
Wouldn't it be good enough to just have the most common use-cases in
setup.cfg? The user can still add code to setup.py to tweak the
default behaviour when the project does something non-standard.
BTW. One way to do conditionals in ConfigParser files might be:
[dependencies.os9]
use-when: python>=2.7, platform=='macos9'
require: unix-toolbox>=2.5
[dependencies.suse]
use-when: file_exists('/etc/SuSE-release')
require: ...
That is, use a config-key in dependency blocks that describes when the
block should be used. The bit after the '.' in de section-name would
be ignored by distutils and would basicly be comment.
Ronald
smime.p7s
Description: S/MIME cryptographic signature
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, Aug 18, 2009 at 05:11:28AM +0300, Alex Grönholm wrote: > How would you declare dependencies? Remember that the list of > dependencies depends on at least two variables: Python version and > platform. Many more, defining a known list of variables to be used to define dependencies is not going to be enough. Maybe there should be a way of having general purpose named conditionals and implement a mapping so that setup.py can define boolean functions for each named conditional. This can then be used for modules etc too instead of just dependencies. The benefit is that you allow developers to specify anything possible, but still allow package management systems to analyse the dependencies and modules etc from static data. They will recognise that something is conditional but are free to do with that knowledge they want. Expressiong conditionals in an elegant-ConfigParser-compatible way might be tricky. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, 18 Aug 2009 06:06:29 +0300, Alex Grönholm
wrote:
> That scheme does not allow me to say "This dependency is required unless
> platform is X". A practical example of this is Beaker, where pycryptopp
> is required for cookie encryption, but works without external
> dependencies on Jython.
Yes, I follow..
That's why I'm so keen on having a pre_setup() and a post_setup()
user routine, where the environment and dependencies can be exposed.
I can't see any easy way to do conditional logic in a config file.
imho it just has to go in code.. and it is as simple as that - haha
for example (demonstration code - not runnable):
"""
from distutils.core import setup
def pre_setup():
if sys.platform() == "linux2":
self.dependencies.append("pycryptopp")
return
setup()
"""
So, one could modify the dependencies dynamically based
on the underlying platform.
Dependencies is a list of packages within the setup class. So
the user can add or remove items before the actual setup() is
done.
> Also, how do I define that this package has a minimum (or maximum)
> required Python version?
[Python_versions]
minimum_supported=2.3
maximum_supported=2.7
We can't tell a user it won't work - only that it isn't supported.
> Or that the distribution is only applicable to a certain platform (say,
> win32 or java)?
[Platforms]
supported1=linux2
supported2=mac
supported3=win32,win64
I think we can let the developer specify what *is* supported, and if it
doesn't
match then give the user the choice to proceed or not. (At their own risk)
David
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Tue, 18 Aug 2009 05:11:28 +0300, Alex Grönholm wrote: > How would you declare dependencies? Remember that the list of > dependencies depends on at least two variables: Python version and > platform. hmm.. they're the most important of all... Perphaps... """ [setup] name: foo version: 1.0 author: tarek long_description: some long description here url: http://example.com [dependencies] dependency1=numpy,>X.Y dependency2=lxml,E.F [dependency_linux2_python2.5] dependency1=gtkwinhelper,>S.T [dependency_mac_python2.4] dependency1=hotplug """ The operating system name should match one of the os.name() or sys.platform() functions.. David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, 17 Aug 2009 18:21:15 -0700, "Sridhar Ratnakumar"
wrote:
> More often developers may want to assign the contents of README.txt to
the
>
> `long_description` field. I have seen setup.py's that simply do:
>
>long_description = open('README.txt').read()
Perphaps:
[setup]
name: foo
version: 1.0
author: tarek
long_description_file: README.txt
> If one is to use setup.cfg, how would this particular case be handled?
> Override `long_description` in setup.py ..
Perphaps.
> or provide a Config variable ($README)?
I'm not keen on that because I don't fully understand it. I think
the first option should be clear enough.
David
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
David Lyon kirjoitti: On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziadé wrote: We can use the [global] section of the setup.cfg file to describe them. My suggestion is [setup] because it directly corresponds to the setup() function. I know it is a triplication of the name (setup.cfg, setup() and then [setup]) but it's much more consistent and will be easier to find for new users. [setup] name: foo version: 1.0 author: tarek long_description: some long description here url: http://example.com And then... How would you declare dependencies? Remember that the list of dependencies depends on at least two variables: Python version and platform. """ from distutils.core import setup setup() """ That's all that it should be (for now... evil grin.. :-) In a commercial level app you always need to do extra stuff. If we can't do this now then fine.. later.. But it needs to be pointed out that these things are somewhat mandatory for python applications, not necessarily packages. """ from distutils.core import setup preinstall() # Read current environment and adjust # installation.. twiddle directory locations # and perphaps make choices dependent on # environment KDE/Gnome/Windows/Mac setup() # run the distutils function postinstall() # Now generate the documentation, register # .dll files, update environment, create # window manager shortcuts etc Regards David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, 17 Aug 2009 17:22:51 -0700, David Lyon
wrote:
[setup]
name: foo
version: 1.0
author: tarek
long_description: some
long description
here
More often developers may want to assign the contents of README.txt to the
`long_description` field. I have seen setup.py's that simply do:
long_description = open('README.txt').read()
If one is to use setup.cfg, how would this particular case be handled?
Override `long_description` in setup.py .. or provide a Config variable
($README)?
-srid
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziadé wrote: > We can use the [global] section of the setup.cfg file to describe them. My suggestion is [setup] because it directly corresponds to the setup() function. I know it is a triplication of the name (setup.cfg, setup() and then [setup]) but it's much more consistent and will be easier to find for new users. [setup] name: foo version: 1.0 author: tarek long_description: some long description here url: http://example.com And then... > """ > from distutils.core import setup > > setup() > """ That's all that it should be (for now... evil grin.. :-) In a commercial level app you always need to do extra stuff. If we can't do this now then fine.. later.. But it needs to be pointed out that these things are somewhat mandatory for python applications, not necessarily packages. """ from distutils.core import setup preinstall() # Read current environment and adjust # installation.. twiddle directory locations # and perphaps make choices dependent on # environment KDE/Gnome/Windows/Mac setup() # run the distutils function postinstall() # Now generate the documentation, register # .dll files, update environment, create # window manager shortcuts etc Regards David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, 17 Aug 2009 09:34:56 +0200, Tarek Ziadé wrote: > Now for the name of the file, I wouldn't want yet another file since > we already have > setup.cfg and since it can be extended w/o any problem or bacward > compatibility issue. The only issue here is that the "new" setup.metadata file that gets sent to pypi won't contain all the private build stuff that is in the developers setup.cfg file. As I understand and correct me if I'm wrong, but there's all sorts of options that you can build in for all the different platforms. The developer won't want all the (irrelevent) stuff sent out.. > I am also realizing that we can use it to describe "static metadata" > almost with the > existing distutils code. Yes. I would agree with that. > We can use the [global] section of the setup.cfg file to describe them. Yes. > If we want to remove all metadata expressed as setup() arguments, we > can just move them > to the setup.cfg. Yes, good thinking. > > example of setup.cfg file: > > """ > [global] > name: foo > version: 1.0 > author: tarek > long_description: some > long description > here > > url: http://example.com > """ > > What's left in setup.py : > > """ > from distutils.core import setup > > setup() > """ > Exactly, that's how simple it should be. > I've changed this in my working trunk to give a try, and it works fine. > > the long_description field is expressed as a multi-line field following > the config parser convention so no problem for it (see my example) Yes. > Although there's another change we need to apply and decide : being > able to express a > list of values, for fields like "keywords" or "classifiers". [Files] file1 = abc.txt file2 = def.txt You can get all the keys in "[Files]" in a list in the configparser class. > Any thoughts ? You are having good thoughts... David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Here we go On Mon, Aug 17, 2009 at 3:54 PM, Tarek Ziadé wrote: > Did I attach the file ? > -- Tarek Ziadé | http://ziade.org site.diff Description: Binary data ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
Did I attach the file ? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
2009/8/17 P.J. Eby : > At 09:34 AM 8/17/2009 +0200, Tarek Ziadé wrote: >> >> Right now the behavior of the code is: >> >> Distutils will take the setup.cfg options and apply them to the >> Distribution class, >> overriding any argument passed to setup(), then they will be in turn >> overriden by >> the command line options if any. >> >> This behavior seems fine. >> >> Now there's a very small change to make in distutils to make this work, >> wich consists of applying these values to the DistutilsMetadata >> object (the metadata attribute in the dist instance) >> >> I've changed this in my working trunk to give a try, and it works fine. > > Are you doing this in setup(), Distribution.__init__, > Distribution.parse_config_files(), Distribution.finalize_options(), or > somewhere else? I'm a bit concerned about backward compatibility, and > integrating e.g. setup_requires. I was thinking about doing it in parse_config_files(), after the files are parsed in the part where the "global" section is applied in the distribution object, I've attached a diff of the dist.py if you want to take a look (that's not the final version but you get the idea) > > One of the consequences of this approach would be that if setuptools tried > to support setup_requires this way, it could end up running recursively by > endlessly re-parsing the same configuration file, and then creating a new > distribution to do the installation, which in turn would parse the config > file and see a setup_requires, and so on. I am not sure to follow this case, would that be through fetch_build_egg ? Tarek -- Tarek Ziadé | http://ziade.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
At 09:34 AM 8/17/2009 +0200, Tarek Ziadé wrote: Right now the behavior of the code is: Distutils will take the setup.cfg options and apply them to the Distribution class, overriding any argument passed to setup(), then they will be in turn overriden by the command line options if any. This behavior seems fine. Now there's a very small change to make in distutils to make this work, wich consists of applying these values to the DistutilsMetadata object (the metadata attribute in the dist instance) I've changed this in my working trunk to give a try, and it works fine. Are you doing this in setup(), Distribution.__init__, Distribution.parse_config_files(), Distribution.finalize_options(), or somewhere else? I'm a bit concerned about backward compatibility, and integrating e.g. setup_requires. One of the consequences of this approach would be that if setuptools tried to support setup_requires this way, it could end up running recursively by endlessly re-parsing the same configuration file, and then creating a new distribution to do the installation, which in turn would parse the config file and see a setup_requires, and so on. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Static metadata using setup.cfg
On Mon, Aug 17, 2009 at 9:34 AM, Tarek Ziadé wrote: > Following the discussion on the format of the static metadata file, > it's evident for me that it has to be a ConfigParser file. Big +1 > I am proposing the current scheme (applying it in this precise order): > > 1/ if the value contains '\n' signs, it's a list and values are > splitted using \n, then each element is left stripped > (not sure yet if we want to right strip them too) > > 2/ if the value contains ',' signs, it's a list and values are > splitted using ',' (not sure yet if we want to strip them) > 3/ else, it's a value I'd generally prefer a full strip() on list entries. People tend to put trailing whitespace into files without noticing it too much. The number of whitespace fanatics is certainly larger in Python cycles, but not among casual developers. Hanno ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Static metadata using setup.cfg
Hello Following the discussion on the format of the static metadata file, it's evident for me that it has to be a ConfigParser file. Now for the name of the file, I wouldn't want yet another file since we already have setup.cfg and since it can be extended w/o any problem or bacward compatibility issue. (That's from Tres and Matthias idea at Pycon) I am also realizing that we can use it to describe "static metadata" almost with the existing distutils code. We can use the [global] section of the setup.cfg file to describe them. If we want to remove all metadata expressed as setup() arguments, we can just move them to the setup.cfg. example of setup.cfg file: """ [global] name: foo version: 1.0 author: tarek long_description: some long description here url: http://example.com """ What's left in setup.py : """ from distutils.core import setup setup() """ Right now the behavior of the code is: Distutils will take the setup.cfg options and apply them to the Distribution class, overriding any argument passed to setup(), then they will be in turn overriden by the command line options if any. This behavior seems fine. Now there's a very small change to make in distutils to make this work, wich consists of applying these values to the DistutilsMetadata object (the metadata attribute in the dist instance) I've changed this in my working trunk to give a try, and it works fine. the long_description field is expressed as a multi-line field following the config parser convention so no problem for it (see my example) Although there's another change we need to apply and decide : being able to express a list of values, for fields like "keywords" or "classifiers". It can be a "," separated list of values, or a "\n" separated one. I am proposing the current scheme (applying it in this precise order): 1/ if the value contains '\n' signs, it's a list and values are splitted using \n, then each element is left stripped (not sure yet if we want to right strip them too) 2/ if the value contains ',' signs, it's a list and values are splitted using ','(not sure yet if we want to strip them) 3/ else, it's a value This allows us to use "," for small lists like keywords we know they will never contain any "," sign, and several lines when the values might contain "," signs. So for example: """ [global] name: foo version: 1.0 author: tarek long_description: some long description here url: http://example.com keywords: one, two, three classifiers = Classifier1 Classifier2 Classifier3 """ Any thoughts ? Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
