On Tue, Nov 9, 2010 at 12:04 PM, Fred Drake wrote:

On Tue, Nov 9, 2010 at 5:58 AM, Geoff Bache wrote:

...

Is this a bug?

I think so.

...

Or have I missed something in my setup.py? It works of course if I remove the generated "build" directory by hand, but it's not so nice to have to remember to do that.

You should be able to remove the build/ directory that was created where the package is unpacked, and then run the install command with your python2/bin/python.  The problem is that "build" and "install" are traditionally two distinct steps.  While setup.py takes care of both for you, it does detect that you switched Python's, so doesn't re-build for the second.

Since we're adding the "configure" command that will let install have an access to all build options that were used, (still in Eric's branch) we should be able to know where the script is in the build tree, and check in install_scripts that its not outdated with the file timestamps + checking the shebang line. Or... keep in that configure file the path to the interpreter and just rebuild all scripts in case the interpreter has changed.

  -Fred

-- Fred L. Drake, Jr.    <fdrake at acm.org> "A storm broke loose in my mind."  --Albert Einstein _______________________________________________ Distutils-SIG maillist  -  Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

-- Tarek Ziadé | http://ziade.org

2010/11/9 Tarek Ziadé :

Since we're adding the "configure" command that will let install have an access to all build options that were used, (still in Eric's branch) we should be able to know where the script is in the build tree, and check in install_scripts that its not outdated with the file timestamps + checking the shebang line.

Or... keep in that configure file the path to the interpreter and just rebuild all scripts in case the interpreter has changed.

In my opinion it might be worthy storing some combination (interpreter path, interpreter build no). Case study: For building some binaries, we are using both py2.7-macosx10.3 and py2.7-macosx10.5 on Mac OS X (obviously), which are different builds but must be installed to exactly the same default location (some technicalities). Of course only one of them is installed at a time. We just recently ran into an error (failure) where we think we used py2.7-10.3 built binaries to make a py2.7-10.5 installer (or vice versa). This came so because the build directory was reused. A solution might be to include the build number or something similar in the build/anything-something directory name. Maybe just add a hash of the tuple (installer path, build no) in the build directory's name? Obviously, then both interpreter path change as well as interpreter build number change would lead to another build directory. Might be useful to be able to use different Pythons in parallel for parallel builds. One could add whatever is needed later to the hashed tuple without breaking compatibility. (E.g., build options :-) Friedrich

Hi Tarek,

Can you add an issue in bugs.python.org please (using the "Distutils2" component and "feature request")

I've added a bug, but felt I had to describe it as I saw it (i.e. a behaviour issue with Distutils). It took me quite some time to track down what was going on, and I didn't think I was doing anything complicated or unusual. It can't be that hard to fix it in distutils can it (as you've just been discussing)? Regards, Geoff