The Windows install of Python 2.7.13 defaults it's install into **C:\Python27**.  It creates several subdirectories within this; one of which is **C:\Python27\lib\site-packages\backports**. So just out of the box (without this script installed):
```python
import backports
print(backports.__path__)
# C:\Python27\lib\site-packages\backports
```

I have a custom package that sets the sys.path(0, "new path") entry which works great in Linux. I ship all my modules and settings in this path.  This to work great in Windows too 'except' for the reference to `backports`.

Consider the block of code:
```python
import sys
from os import getcwd
from os.path import join
sys.path.insert(0, join(getcwd(), 'MyLibraries'))

# Now if we import backports, we should find the one in our MyLibraries directory
import backports
print(backports.__path__)    # Nope... :(
# C:\Python27\lib\site-packages\backports

# What's weird is it's not entirely broken... you can do the following:
import chardet
print(chardet.__path__)
# Prints my path to MyLibraries/chardet
# So the path is correct and other libraries are coming in correctly
```

What's really weird, is (in Windows) even if i delete the **C:\Python27\lib\site-packages\backports**, it still imports the module; so it's like part of the Python27 build in some way.

`pip install` with the backports module I want works great because it drops the correct package in this 'lib/site-packages\backports' directory which is constantly being referenced.

From what I can see the Microsoft version of Python27 can't seem to stop referencing (even when told not to) the _backports_ location. Linux works perfectly (as intended) but having customers port to this isn't an option for me.