Sounds nice,
Looks like it could make building distributions based on c-libraries
more predictable (think lxml or pymsql), specially when you explicitly
want to avoid libraries provided by the system.
Of course, it would only be helpful for me if buildout grew support
for tweaking it somehow.
Cheers,
Leo
On Mon, Jan 28, 2013 at 12:24 PM, Manlio Perillo
<manlio.peri...@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi.
>
> Recently I have started a new project that needs some runtime configuration.
>
> All the open sources projects I have reviewed, do the configuration step
> by usually deriving from the build_ext command class, and then execute
> some configuration code to set required options.
>
> This result in what I believe is bad design, and in some cases the
> setup.py ends up in a unreadable mess of code.
>
> I think that the setup.py should be as much as declarative as possible.
>
>
> I have studied the distutils source code, where I found a config command.
> Unfortunately this command is never used by other commands, e.g., the
> build_ext does not call self.set_undefined_options('config', ...)
>
> Another problem is that you have to do something like this:
>
> $ python setup.py \
> config --pg_config=/usr/local/pgsql/bin/pg_config \
> build
>
> every time you need to build code (e.g. during development).
>
>
> This is the reason a decided to write an "improved" config command; I
> have attached a sample implementation.
>
> The new config command does the following:
>
> If config.dat (adjacent to setup.py file) does not exists, or if user
> has explicitly executed the config command or if setup.cfg is
> newer than config.dat, then:
>
> call the configure method (that user must override), and then save
> all options to config.dat file, using pickle
> (XXX the code here is a bit tricky [1])
>
> otherwise, load the config.dat file and set options in the config
> command instace.
>
>
> This implementation allow users to use the traditional configure + make
> pattern:
>
> $ python setup.py config --pg_config=/usr/local/pgsql/bin/pg_config
> $ python setup.py build
> $ sudo python setup.py install (or develop, using setuptools)
>
>
> A project that needs runtime configuration, will create a config.py
> module (adjacent to setup.py) file, and will define a custom config
> command, derived from the provided class.
>
> The setup.py file will import the config module, and will use the
> cmdclass setup option to register the new command.
>
>
> The next step is to implement an "improved" build_ext command, that will
> use options from the config command, as default values.
>
>
> [1] a better solution is to have the configure method return a
> dictionary, but it is more verbose
>
>
>
> Feedback is appreciated.
>
>
>
> Thanks Manlio Perillo
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlEGihoACgkQscQJ24LbaURAwwCfULYAQg7yOWPzRNFJZ+YobvRG
> oUkAoIqm43SfWg9AdjurrYqui4tjVWse
> =PeN3
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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
