sys.path order incorrect on Windows

Bug #583033 reported by James J Myers
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Django Recipe
In Progress
Undecided
Unassigned

Bug Description

I have Django 1.1 installed in Windows. I am using buildout to create a Django installation using Django 1.2.

The generated sys.path in django.wsgi-script.py (and the other scripts) has this:

  'c:\\python26\\lib\\site-packages',
  'c:\\home\\dhat\\webapps\\portal-1.0\\myproject\\parts\\django',

which makes the new installation use the system Django, not the buildout version needed.
If I reorder those 2 lines it works correctly.

Here's my buildout.cfg:

[buildout]
parts = python django django-patches css dojo
develop = .
eggs = django-notify
    dojango
    django-maintenancemode
    xlrd
    xlwt
    titlecase
portal_python = 2.6
portal_django = 1.2
dojango_version = dojango-0.4.6-py${buildout:portal_python}
dojo_version = 1.4.2
download-cache = ${buildout:directory}\..\download-cache

[python]
recipe = zc.recipe.egg
interpreter = python
eggs = ${buildout:eggs}

[django]
recipe = djangorecipe
version = ${buildout:portal_django}
project = myproject
projectegg = myproject
settings = settings
wsgi = true
#wsgilog = ${buildout:directory}\var\rp.log
extra-paths = ${buildout:directory}\..
       ${buildout:directory}\portal
eggs = ${buildout:eggs}
test = portal
    events

[django-patches]
# fix for Django ticket 11797
# support Dojo 1.4 in Dojango
recipe = iw.recipe.cmd
on_install = true
on_update = true
cmds =
 copy ${buildout:directory}\patches\1.2\client.py ${buildout:directory}\parts\django\django\test
 copy ${buildout:directory}\patches\dojango\conf\settings.py ${buildout:directory}\eggs\dojango-0.4.6-py2.6.egg\dojango\conf

[css]
recipe = iw.recipe.cmd
on_install = true
on_update = true
cmds =
 mkdir ${buildout:directory}\..\var
 mkdir ${buildout:directory}\var
 mkdir ${buildout:directory}\var\django_cache
 mkdir ${buildout:directory}\var\django_sessions
 mkdir \home\dhat\portal\rp
 mkdir \home\dhat\portal\rp\teacher
 mkdir \home\dhat\portal\admin
  xcopy ${buildout:directory}\rp\* \home\dhat\portal\rp /E /D /Y
  copy ${buildout:directory}\config\${buildout:portal}\settings_local.py ${buildout:directory}
  copy ${buildout:directory}\bin\django.wsgi-script.py ${buildout:directory}\..\myproject.wsgi

[dojo]
recipe = hexagonit.recipe.download
strip-top-level-dir = true
destination = ${buildout:directory}/eggs/${buildout:dojango_version}.egg/dojango/dojo-media/src/${buildout:dojo_version}
url = http://download.dojotoolkit.org/release-${buildout:dojo_version}/dojo-release-${buildout:dojo_version}-src.tar.gz

Revision history for this message
grep (maxim-razin) wrote :

The same problem on Ubuntu 10.04.

buildout finds one of the needed modules under the generic Python library path '/usr/lib/pymodules/python2.6', and inserts it before the correct django path 'PROJECTDIR/parts/django'.

Looks like a bug in buildout (I would prefer if buildout inserted extra-paths before eggs).

Revision history for this message
roland (roland-micite) wrote :

Thanks for reporting this.

Does this issue still exist with the new 0.99 release?
Djangorecipe now has django as a dependency and isn't installed in parts anymore.

Changed in djangorecipe:
status: New → In Progress
Revision history for this message
James J Myers (myersjj) wrote : Re: [Bug 583033] Re: sys.path order incorrect on Windows

After doing the changes to use 0.99, I got this error. Shouldn't it
upgrade in this case?

While:
   Installing.
   Getting section django.
   Initializing section django.
   Installing recipe djangorecipe.
Error: There is a version conflict.
We already have: Django 1.2.4

After I manually uninstalled using pip, the build completed OK.
Here is the myproject.wsgi it generated (the offending line is still
there)...

#!"C:\python26\python.exe"

import sys
sys.path[0:0] = [

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\eggs\\dojango-0.5.1-py2.6.egg',

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\eggs\\xlrd-0.7.1-py2.6-win32.egg',

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\eggs\\xlwt-0.7.2-py2.6-win32.egg',

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\eggs\\titlecase-0.4-py2.6.egg',

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\eggs\\whoosh-1.8.4-py2.6.egg',

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\eggs\\djangorecipe-0.99-py2.6.egg',

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\eggs\\django-1.2.5-py2.6.egg',

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\eggs\\zc.recipe.egg-1.3.2-py2.6.egg',

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\eggs\\zc.buildout-1.5.2-py2.6.egg',
     'c:\\python26\\lib\\site-packages',
     'c:\\home\\dhat\\webapps\\dd_django\\myproject\\parts\\django',
     'c:\\home\\dhat\\webapps\\dd_django\\myproject',
     'c:\\home\\dhat\\webapps\\dd_django',
     'c:\\home\\dhat\\webapps\\dd_django\\myproject\\portal',
     'c:\\home\\dhat\\webapps\\dd_django\\myproject\\djangobb_forum',
     'c:\\home\\dhat\\webapps\\dd_django\\myproject\\faq',

'c:\\home\\dhat\\webapps\\dd_django\\myproject\\parts\\django-haystack',
   ]

import djangorecipe.wsgi

application = djangorecipe.wsgi.main('myproject.settings', logfile='')

On 6/7/2011 7:41 AM, roland wrote:
> Thanks for reporting this.
>
> Does this issue still exist with the new 0.99 release?
> Djangorecipe now has django as a dependency and isn't installed in parts anymore.
>
> ** Changed in: djangorecipe
> Status: New => In Progress
>

--

Jim Myers

The TBone way, perfection is sacrificed for energy and impact.

Revision history for this message
roland (roland-micite) wrote :

Well, Django is now installed as an egg, so that means that it comes before your system django.

The other thing, please don't install site-packages that have different versions then you need for your buildout.
However, you can exclude site-packges from your buildout.
Please read http://pypi.python.org/pypi/zc.buildout/1.5.2#working-with-a-system-python for more information.

Revision history for this message
Simeon Movchan (c1n1c) wrote :

I have Django 1.3 in system python site-packages and I tried several configuration options.

First config works fine:

[buildout]
parts =
  django
eggs =
  docutils
  feedparser
  ipython
  pil
  south
include-site-packages = false
versions = versions

[versions]
django = 1.2.5

[django]
recipe = djangorecipe
project = fooproject
settings = development
eggs = ${buildout:eggs}

It produces the following sys.path in django command script:

sys.path[0:0] = [
    'c:\\workspace\\buildtest\\eggs\\docutils-0.8-py2.7.egg',
    'c:\\workspace\\buildtest\\eggs\\feedparser-5.0.1-py2.7.egg',
    'c:\\workspace\\buildtest\\eggs\\ipython-0.10.2-py2.7.egg',
    'c:\\workspace\\buildtest\\eggs\\pil-1.1.7-py2.7-win32.egg',
    'c:\\workspace\\buildtest\\eggs\\south-0.7.3-py2.7.egg',
    'c:\\workspace\\buildtest\\eggs\\djangorecipe-0.99-py2.7.egg',
    'c:\\workspace\\buildtest\\eggs\\django-1.2.5-py2.7.egg',
    'c:\\workspace\\buildtest\\eggs\\zc.recipe.egg-1.3.2-py2.7.egg',
    'c:\\workspace\\buildtest\\eggs\\zc.buildout-1.5.2-py2.7.egg',
    'c:\\workspace\\buildtest\\eggs\\setuptools-0.6c12dev_r88846-py2.7.egg',
    'c:\\workspace\\buildtest\\parts\\django',
    'c:\\workspace\\buildtest',
    ]

Everything is good, except 'c:\\workspace\\buildtest\\parts\\django'. Django lives in eggs dir, not in parts. Although it does not matter.

However, if I want to use several dependencies from site-packages by specifying them with allowed-eggs-from-site-packages, I get a version conflict:

While:
  Installing.
  Getting section django.
  Initializing section django.
  Installing recipe djangorecipe.
Error: There is a version conflict.
We already have: Django 1.3

Second config that causes version conflict:

[buildout]
parts =
  django
eggs =
  docutils
  feedparser
  ipython
  pil
  south
allowed-eggs-from-site-packages = pil
versions = versions

[versions]
django = 1.2.5

[django]
recipe = djangorecipe
project = fooproject
settings = development
eggs = ${buildout:eggs}

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.