On Fri, Nov 13, 2009 at 6:22 AM, David Cournapeau <da...@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 ? 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: install configure build all the install_* But if we want to see this working with "build" alone, configure has to be a subcommand of build: install build configure all the install_* IOW this would just require: 1/ adding a "configure" command 2/ inserting it as the first sub command of "build" 3/ make it possible, to share in the whole chain of commands, the passed arguments Tarek _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig