On Thu, Nov 12, 2009 at 3:06 PM, David Cournapeau <courn...@gmail.com> wrote: [..] >> >> I was not referring to the finalized options of any commands, but to >> the build paths you are trying to get. > > But those are linked. Build directories are customizable through > pretty much any build_command (I see at least build_clib, build_ext > and build on python 2.6).
yes, like install can customize the install paths with --prefix. but at the end, they you just give them root paths, or things like that, and they return build paths. So, as we said for the install command, this mechanism can be extracted and put in an API, that takes variables to generate build paths, and that can be used by those commands. Meaning that you won't need them anymore to get your build paths. > > So : > >> >> get_build_paths(scheme, vars) >> > > This should return different value depending on whether the in place > build is set up, or the develop command is called, etc... yes, like platlib and purelib. Build schemes will have several paths indeed. we need to list them. > >> If at some point you need to look to some of its finalized options in >> another commandB, it means that >> - either commandA is doing more than it is supposed to do: it sets an >> *environement* that is reused by others >> - either commandB should be a subcommand of commandA >> - either commandA doesn't let you do what you want, and you are >> building a competiting command > > Those differences do not make much sense. If distutils wants command > foo to be a subcommand of bar, and we need a different ordering, how > can we do it ? I don't understand this question. What is the need for you to order two commands ? This pattern is useful only if a command uses what another command has produced. For example: $ python setup.py sdist upload -> upload requires sdist to be run so it can upload an archive If ordering means that you need a command to be run, so you can get its finalized options for your own command, something is wrong. It means that you are unable to build a command that is standalone, and that instead of using an API or the Distribution class on its own, you need to work with another command. That is what wee need to change, by externalizing for the commands the code so you can reuse that. [..] >> >> $ python setup.py --var1 --var2 --var3 cmd1 cmd2 cmd3 >> >> >> then, var1, and var2 etc.. are put in a "vars" dict, that is passed >> to get_paths(scheme, vars). > > As mentioned above, please keep in mind that many of those options see > their behavior modified (directly or indirectly) through commands > options. Think about inplace option, develop command, etc... What's an option behavior ? You mean the value is changed ? The develop command is not part of Distutils and it's doing a big hack on calling the build_ext command and changing the inplace option on the fly like this. It should instead, like what the upload command does, leave it up to any build command to build the extensions in place. And just work on adding a .pth file for example, that adds the source to the path. That would prevent troubles. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
