Problem with Python Egg Cache

[Schol-R-LEA]

I am making a last-ditch effort to get Django 1.3 configured to talk to SQL Server (both running on the same Windows 7 system), before I have to make a final decision whether to move on to ASP.NET instead. I am using PyODBC (I had tried PyMSSQL but was recommended by one of the developers to switch) and Django-PyODBC as the database driver. I have been able to get manage.py syncdb to work, despite continued problems running the PyODBC test programs, and have tried accessing http://localhost/ in my browser, but with the current configuration, I get the following error:

Request handler failed

Traceback (most recent call last):
  File "C:\Python26\Lib\site-packages\AllProBugProWeb\Http\Isapi.py", line 67, in Request
    return RunWSGI(Handler, Base=Base)
  File "C:\Python26\Lib\site-packages\AllProBugProWeb\Http\WSGI.py", line 155, in RunWSGI
    Result = Application(Environ, StartResponse)
  File "c:\Python26\Lib\site-packages\django\core\handlers\wsgi.py", line 250, in __call__
    self.load_middleware()
  File "c:\Python26\Lib\site-packages\django\core\handlers\base.py", line 39, in load_middleware
    for middleware_path in settings.MIDDLEWARE_CLASSES:
  File "c:\Python26\Lib\site-packages\django\utils\functional.py", line 276, in __getattr__
    self._setup()
  File "c:\Python26\Lib\site-packages\django\conf\__init__.py", line 42, in _setup
    self._wrapped = Settings(settings_module)
  File "c:\Python26\Lib\site-packages\django\conf\__init__.py", line 87, in __init__
    mod = importlib.import_module(self.SETTINGS_MODULE)
  File "c:\Python26\Lib\site-packages\django\utils\importlib.py", line 35, in import_module
    __import__(name)
  File "C:\Python26\Lib\site-packages\AllProBugProWeb\proj\settings.py", line 3, in 
    import pyodbc
  File "build\bdist.win32\egg\pyodbc.py", line 7, in 
  File "build\bdist.win32\egg\pyodbc.py", line 4, in __bootstrap__
  File "c:\Python26\Lib\site-packages\pkg_resources.py", line 882, in resource_filename
    self, resource_name
  File "c:\Python26\Lib\site-packages\pkg_resources.py", line 1351, in get_resource_filename
    self._extract_resource(manager, self._eager_to_zip(name))
  File "c:\Python26\Lib\site-packages\pkg_resources.py", line 1373, in _extract_resource
    self.egg_name, self._parts(zip_path)
  File "c:\Python26\Lib\site-packages\pkg_resources.py", line 962, in get_cache_path
    self.extraction_error()
  File "c:\Python26\Lib\site-packages\pkg_resources.py", line 928, in extraction_error
    raise err
pkg_resources.ExtractionError: Can't extract file(s) to egg cache

The following error occurred while trying to extract file(s) to the Python egg
cache:

  [Error 183] Cannot create a file when that file already exists: 'C:\\Windows\\system32\\config\\systemprofile'

The Python egg cache directory is currently set to:

  C:\Windows\system32\config\systemprofile\AppData\Roaming\Python-Eggs

Perhaps your account does not have write access to this directory?  You can
change the cache directory by setting the PYTHON_EGG_CACHE environment
variable to point to an accessible directory.

I have re-installed Setup-Tools and PyODBC, and have set the PYTHON_EGG_CACHE environment variable to the directory C:\Python_Eggs, but it still tries to access the system folders.

[TrustyTony]

Did you try to remove that file? ([Error 183] Cannot create a file when that file already exists: 'C:\\Windows\\system32\\config\\systemprofile')

[Schol-R-LEA]

No; it is actually a directory, not a file per se, and it contains files the system needs.

[TrustyTony]

It says then it tries to create file with name of existing folder and fails as it should.

[Schol-R-LEA]

It says then it tries to create file with name of existing folder and fails as it should.

Well, yes. The issue is that it ought to be using the path given in PYTHON_EGG_CACHE, but it appears to have a hard-coded path instead. I've looked up similar cases, and found several references to similar (but not quite identical) problems, but haven't found any solutions to it so far.

[Schol-R-LEA]

UPDATE: The PYTHON_EGG_CACHE issue seems to have resolved itself silently, which is almost as perplexing as the problem in the first place. However, I am now back at another problem I've had, namely that I am getting an import error when loading PyODBC:

Request handler failed

Traceback (most recent call last):
  File "C:\Python26\Lib\site-packages\AllProBugProWeb\Http\Isapi.py", line 67, in Request
    return RunWSGI(Handler, Base=Base)
  File "C:\Python26\Lib\site-packages\AllProBugProWeb\Http\WSGI.py", line 155, in RunWSGI
    Result = Application(Environ, StartResponse)
  File "c:\Python26\Lib\site-packages\django\core\handlers\wsgi.py", line 250, in __call__
    self.load_middleware()
  File "c:\Python26\Lib\site-packages\django\core\handlers\base.py", line 39, in load_middleware
    for middleware_path in settings.MIDDLEWARE_CLASSES:
  File "c:\Python26\Lib\site-packages\django\utils\functional.py", line 276, in __getattr__
    self._setup()
  File "c:\Python26\Lib\site-packages\django\conf\__init__.py", line 42, in _setup
    self._wrapped = Settings(settings_module)
  File "c:\Python26\Lib\site-packages\django\conf\__init__.py", line 89, in __init__
    raise ImportError("Could not import settings '%s' (Is it on sys.path?): %s" % (self.SETTINGS_MODULE, e))
ImportError: Could not import settings 'proj.settings' (Is it on sys.path?): DLL load failed: The specified procedure could not be found.

Not that it matters much anymore, as the time I had to try and resolve this has past; despite the preference of both myself and my manager for Python, we have to move forward on this project, which means setting Django aside and going with ASP.NET and C#. Thank you for your efforts, in any case.

[Schol-R-LEA]

Before I mark this as solved (or at least resolved), I'd still like to actually see what could be done for this, in case it or something similar arises in the future.

[TrustyTony]

http://bitnami.org/stack/djangostack might be for you.

[Schol-R-LEA]

Under other circumstances, I would agree; normally, I would have used a MySQL database and been done with it. However, the crux of the problem is that there is an existing MS-SQL database which I need to build a front end for, which means connecting to SQL Server is the paramount priority. I didn't mention this before, though in retrospect I should have.