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
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 wo
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()
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 wri
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
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
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
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'
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 co
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
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"
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.platf
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
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
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 co
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_decripti
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
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="
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 s
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 lib
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, ot
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 pa
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/dir
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 ju
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 libr
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:
* dep
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 distu
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
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 witho
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:
>
> -
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
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 anythi
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
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
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 b
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 t
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 h
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...
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
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 tr
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 backwar
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 th
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.s
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 t
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 con
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
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
tar
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,
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
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,
fo
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 var
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 goi
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 Jyt
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
a
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
ver
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, se
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:
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
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
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/
Did I attach the file ?
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
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
>>
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 beha
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'
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
65 matches
Mail list logo
