[Distutils] People want CPAN
floris.bruynooghe at gmail.com
Fri Nov 13 13:18:32 CET 2009
On Fri, Nov 13, 2009 at 11:26:23AM +0100, Tarek Ziadé wrote:
> On Fri, Nov 13, 2009 at 6:22 AM, David Cournapeau
> <david at ar.media.kyoto-u.ac.jp> wrote:
> > Tarek Ziadé wrote:
> >> A deprecation warning would be added in install, if it finds a local
> >> option, rather
> >> than a global. Meaning both would work in 2.7/3.2.
> > If changing the command line in incompatible ways is acceptable, what do
> > you think of scrapping the commands (at the UI level only) altogether ?
> > This would be more consistent and easier to deal for the user, and
> > easier to implement as well:
> > python setup.py configure --option1 --option2=value2 ....
> > python setup.py build
> > python setup.py install
> > We could then make this work:
> > python setup.py install (would run both build and configure implicitly).
> > Making all finalized options available at the build stage would then be
> > easier.
> Is that scraping, or just preparing finalized options using "configure" ?
> Meaning other command would just have to get them when they run, if present ?
> How would that work ? configure would create a file ?
That would be the obvious solution. Both autoconf and CPAN do this by
my understanding so it's a pretty logical thing to do.
> It seems that you are pushing all the work in the "configure" option,
> wich is fine to me,
> but it also looks like you can already achieve this with the existing
> system, by
> changing the subcommands that are in the install command and their
> order. That is:
> all the install_*
> But if we want to see this working with "build" alone, configure has
> to be a subcommand of build:
> all the install_*
Would it not be harder to add new command (or "build tasks") that
require information from the configure step in you structure it like
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
More information about the Distutils-SIG