python imports from the current working directory on win32

Asked by John A Meinel on 2006-07-19

This isn't really a bzr bug, but bzr runs into this bug with python. And this helps document what is going on.

With a default python installation and win32, the current working directory is always added to 'sys.path'. Even when running a script from another directory. (apparently this sometimes happens on freebsd as well)

It would seem that the default sys.path starts with:

[<dir of the script>, <dir of python24.zip>, '', ...]
Where '' is the empty string.
In 'site.py' the function 'removeduppaths' expands the empty string to the current working directory and updates sys.path.

According to 'cosmit' on IRC, python2.5 actually has '' happen *before* python25.zip. Which means files in the current working directory get imported before system files, even when running a script from another dir.

Either way, the current working directory should only be present in sys.path if the script is being run from the current directory.

It should be possible to change site.py to behave correctly by removing '' from the list of paths.

Note: this function runs *before* dirname(sys.argv[0]) is added, so it should be safe to always remove '' from the list of paths.

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Last query:
2006-07-19
Last reply:
2007-11-30
John A Meinel (jameinel) said : #1

Attached patch seems to fix the bug for win32, but should be tested thoroughly.

Alexander Belchenko (bialix) said : #2

This is the bug in python itself, not in bzr.
I know this bug and I always keep it in mind when working with my python code. (That's why I wrote my make_bat.py utility).

I don't think we should change standard Python files.

We can suggest your fix in FAQ for windows user.

Alexander Belchenko (bialix) said : #3

This win32 behaviour is changed in Python 2.5.
In Python 2.5 current directory no more automatically added to sys.path.

Alexander Belchenko (bialix) said : #4

I don't think it's a bzr bug. I'd prefer to change it to wontfix.

Robert Collins (lifeless) said : #5

On Fri, 2007-11-23 at 21:05 +0000, Alexander Belchenko wrote:
> I don't think it's a bzr bug. I'd prefer to change it to wontfix.

Python itself can cause it, it's true. That is, if '' is on sys.path,
bzr will load from the cwd.

While I don't think bzr causes this, we should make sure we work
correctly when it happens.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Alexander Belchenko (bialix) said : #6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins пишет:
> On Fri, 2007-11-23 at 21:05 +0000, Alexander Belchenko wrote:
>> I don't think it's a bzr bug. I'd prefer to change it to wontfix.
>
> Python itself can cause it, it's true. That is, if '' is on sys.path,
> bzr will load from the cwd.
>
> While I don't think bzr causes this, we should make sure we work
> correctly when it happens.

In my understanding it's completely impossible to achieve this goal
because of broken design of our underlying platform: CPython interpreter.
I.e. we can't guarantee for all possible use cases that bzrlib will
work out gracefully any malicious or random attempt to import bad module
instead of standard one. It's just problem of python programers,
who write their own python programs an use module names that identical
to standard library ones.

Because now bzrlib uses full python-path to their own internals, the only
problem here is standard library. And we can't workaround this. At least
I don;t see the way.

We can provide guard code only in bzr script, IMO.
Because I have use case that annoys me for last 2 years:
if I have bzr installed for my Python (i.e. in site-packages) and
I cd to bzr sources directory, then running system-wide bzr I constantly
have problems because bzr try to import bzrlib from current directory
first not from site-packages. This problem is fixable in my understanding:
replace '' in sys.path with full path to running bzr script itself.
And I'm about to provide patch to fix it in bzr script (only).

But at the bzrlib level we can't and shouldn't manipulate with sys.path.
It's my strong IMO.

Newer version of Python interpreter also try to address this problem
via absolute import mechanism. We (bzrlib) can't do it instead of Python.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHR98RzYr338mxwCURApwMAKCMCrA3KVbfrGn0k+0Fp2UezeWN4ACeKuoV
7uGKY3JuFOz1m4/9NHWp0JY=
=OtXe
-----END PGP SIGNATURE-----

Martin Pool (mbp) said : #7

It seems to me from the list that we've decided it's not a bzr bug, so I'm going to mark it wontfix.

Martin Pool (mbp) said : #8

solved for now, retaining it as a question