On Tue, Aug 18, 2009 at 1:26 PM, Eric Smith<e...@trueblade.com> 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
