--user installation leaves bzr.bat broken on other systems

[Sridhar Ratnakumar]

When bzr was installed into PEP 376 style user directory on Windows (i.e., %APPDATA%\Python), it breaks bzr.bat which has hardcoded path to the 'bzr' script. Here's a patch we use with ActivePython/PyPM to correct this. This assumes that 'bzr' has in its shebang the path to python interpreter.

setuptools' entry points uses a similar approach by reading shebang line from the corresponding file and then launching that interpreter.

We also patched mercurial (hg.bat) to behave like this.

Index: bzr-2.2b4/setup.py
===================================================================
--- bzr-2.2b4.orig/setup.py 2010-08-19 10:33:38.095078386 -0700
+++ bzr-2.2b4/setup.py 2010-08-19 10:35:52.715083786 -0700
@@ -106,6 +106,21 @@
 # Overridden distutils actions
 ###############################

+apy_bzr_bat = r'''
+@echo off
+rem Windows Driver script for Bazaar
+
+setlocal
+set BZR=%~f0
+
+rem Use the Python interpreter specified in the shebang of `bzr'
+
+set /p SHEBANG=<"%~dp0bzr"
+set PYTHON=%SHEBANG:~2%
+
+%PYTHON% "%~dp0bzr" %*
+endlocal
+'''
 class my_install_scripts(install_scripts):
     """ Customized install_scripts distutils action.
     Create bzr.bat for win32.
@@ -123,7 +138,7 @@
                 batch_str = "@%s %s %s" % (python_exe, script_path, args)
                 batch_path = os.path.join(self.install_dir, "bzr.bat")
                 f = file(batch_path, "w")
- f.write(batch_str)
+ f.write(apy_bzr_bat)
                 f.close()
                 print("Created: %s" % batch_path)
             except Exception:

[Sridhar Ratnakumar (srid)]

Well, actually 'script_path' was generated on the build machine .. but script_path will vary on the user's machine. So this may not be reproduced when you actually do "python setup.py install --root=i" ... nevertheless, this patch makes bzr.bat static ... therefore my_install_scripts can be removed from setup.py (less code == good).

[Martin Packman (gz)]

Moving complexity from sane python to crazy batch hacks strikes me as a bad idea. Is the only issue here is the edge case of building on one machine then using those files on another machine? Either Don't Do That, or wouldn't something simpler like optionally taking the script_path as a setup parameter work?

[Sridhar Ratnakumar (srid)]

Well, we do this in PyPM, a cross-platform binary package manager ... which necessitates that the build happens on a separate machine.
http://pypm.activestate.com/

I did not realize (as I did in comment #1) that this doesn't affect normal users, when I filed this bug. So feel free to kill it unless any of you find the static version to be better.

[Martin Packman (gz)]

I'm interested in fixing the root problem here, I just don't quite understand your package manager's requirements.

I'm looking at your build log here:
<http://pypm-free.activestate.com/2.7/win32-x86/pool/b/bz/bzr-2.2.0_win32-x86_2.7_1.pypm.d/log>

So, distutils makes the script shebang point at the right python during build_scripts and this is happening on your build machine:

    running build_scripts
    creating build\scripts-2.7
    copying and adjusting bzr -> build\scripts-2.7

What, if anything, do you then do to the script files at install time? If nothing, how is the python shebang at the top of script pointing at the right place if I could install ActivePython in a directory of my choosing? And why is the same path in the bat file any more of a problem?

[Sridhar Ratnakumar (srid)]

> I'm looking at your build log here: [snip]

Note that that is using our patched version of bzr (same as the patch in the bug description).

> how is the python shebang at the top of script pointing at the right place

That happens on the user's machine (client). PyPM fixes the shebang line during post-installation ...

> And why is the same path in the bat file any more of a problem?

.. because PyPM only fixes shebang for files that already have it (which is typical for most packages, such as the one using setuptools entry_points even on Windows), and the bzr batch file does not have it.

i.e., pypm automatically fixes shebang in Scripts/bzr - but not Scripts/bzr.bat. Thus, we patched bzr.bat to use the Python interpreter specified in ./bzr.

> I'm interested in fixing the root problem here

The root problem, I suppose, is that bzr's setup.py plainly assumes that the path to Python interpreter remains static from (a) the time "python setup.py build" is run to (b) the point the user can use that package. However, (a) and (b) can happen on a different machine, which is the case with PyPM and possibly with future Windows package managers (I recall one from codeplex or port25)

[Alexander Belchenko (bialix)]

Sridhar Ratnakumar пишет:
>> I'm interested in fixing the root problem here
>
> The root problem, I suppose, is that bzr's setup.py plainly assumes that
> the path to Python interpreter remains static from (a) the time "python
> setup.py build" is run to (b) the point the user can use that package.
> However, (a) and (b) can happen on a different machine, which is the
> case with PyPM and possibly with future Windows package managers (I
> recall one from codeplex or port25)

I disagree with your point. bzr's setup.py script creates bzr.bat
during execution of "python setup.py install" command and not "python
setup.py build" because of the reasons you have explained before.

But to support your or another package manager this is not enough. In
my opinion package manager machinery is not quite compatible with
standard distutils machinery, therefore we have conflict of different
approaches.

@Martin gz: I think we should just merge the proposed patch with clear
explanation why it so.

[Alexander Belchenko (bialix)]

This bug is about changes in bzr's setup.py and it's unrelated to windows installers.