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
<mini rant>
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.
</rant>
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 - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
