On Thu, Nov 12, 2009 at 11:25 AM, David Cournapeau <da...@ar.media.kyoto-u.ac.jp> wrote: > Tarek Ziadé wrote: >> >> The build and instalation scheme should be part of the API. If you >> look in sysconfig, >> you get most of the install schemes via the API. If anything is >> missing, tell us. > > (I am reading the code there: > http://svn.python.org/projects/python/branches/tarek_sysconfig/Lib/distutils/sysconfig.py) > > I have not tried running the code, but here is what I see missing: > - anything related to build (where are libraries put in the build > directory, where are the extensions put - necessary if you are > interested in inter-operating with make)
the build part will not be in sysconfig, and wil stay in distutils, because I don't think the rest of the stdlib cares about it. Now, there's no reason at all that we can''t add an API in distutils.util for example, that let you get the build paths, and that will be used by all build_ commands, so you don't have to use a build_ command to get them. I propose that you think about its signature, and that I add it after we agree on it. > - I don't see the equivalent of > distutils.command.install.install_libbase and similar prefixes That's platlib or purelib, depending on wether you have an extension or not. Those are the default schemes and all $VARIABLE in there can be overriden by the end user, that's why you have this expansion mechanism. > - How can we retrieve the full customized install path ? I have not > found how I could use the code in sysconfig to solve the use case I have > written about before (related to retrieving install prefix). > by calling "get_paths(scheme, vars)", where scheme is the installation scheme you want (unix, nt, etc) and vars your variables if you want to override any $VARIABLE. >> >> Now for the build I am not sure what you are trying to perform here. [...] > > So the list of variables needed: > - everything in sysconfig (but available for any compiler, including > MS ones) > - any distutils command option. What is needed here is a way to > query the options given to command globally, that is the possibility to > access at any point in your setup.py every option of every command, > without running them as first as we have to do currently (like running > install_cmd within build_clib). You mean, accessing other commands command line options ? or the result of their finalizations ? For me, the install_cmd <-> build_clib problem shows that the "install" command do some work that is needed by other commands, and that this work has to be taken out of it. A command performs something, and should not be used to set up an *environment*. What are the other commands you run to get information on the environment ? [..] > > Right now, I have to reimplement the distutils code to find those, as > the logic is not available through API. Generally, the build directories > are only known through the corresponding build_* commands, but they > become available only after running the commands, which we want to avoid. I'd like to change that then. That's one thing we can change without any problem. Refactoring the build commands so they use some APIs that are outside them, make sense. And will allow you to get the information without having to run in some command calls madness. >> And I made a proposal for this last one too in this thread. But, like >> the Extensions proposal I have made, >> you seem not to hear them. > > Because I genuinely don't understand why it is required not to replace > distutils but it is ok to change its behavior in a fundamental way. It seems that some of Distutils knowledge is located in some commands, and that this knowledge could be pushed out in simple APIs, that could be used in the build_ commands, but also in your commands. Do you agree that this change will help you, and is possible without replacing Distutils ? > >> Sorry, but that's pretty vague. Are you mentioning the changes in >> build_ext, or something else ? > > For 2.6.3, yes. For python 2.6, the mingw support was broken because of > VS manifests; our fortran tools were broken because the msvc compiler > was change (to msvc9compiler). There were also some other changes > related to install directories and the --local option in 2.6 which > caused issues. Several setuptools have also broken various parts of our > own extensions in the past. If you really need to know the details for > the last ones, I can look back in our svn log. I fully agree that some commands like build_ext are leading to some of this problems. For that I have a partial solution until it's redesigned : buildbot. I remember I broke Numpy once. So I've worked on a buildbot that tries to prevents regressions. This one: http://buildbot.ziade.org/waterfall , as a matter of fact, is grabbing Numpy and builds it with 2.5, 2.6, 2.7 etc to make sure the "sdist" command still works and to make sure that the produced tarball is the same all the time (on the 1.3.0 tag) I am pretty sure it can be ehnanced to protect more things on your side. Help is welcome. Tarek _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
