Re: Migrating a Django project to new platform

[Cal Leeming [Simplicity Media Ltd]]

That's strange, sorl-thumbnail didn't seem to resolve your problem.

First thing I'd do is identify the line of code that is causing this import problem (do a search for 'sorl' in your code base). From there, identify some of the function names being called on sorl in your application, and add those to the Google search. That might help identify what the module is and where you can find it. 

Let us know what you find!

Cal

On Wed, Oct 3, 2012 at 12:51 PM, Elliot <elliot....@hayley-group.com> wrote:

Hi all,

I would like some help or advice migrating an old Django project to a different platform.

Firstly, I am ok-ish with linux (mainly CentOS), and created basic websites, MySQL/PHP/HTML intranets, but know next to nothing about Django or CMS systems in general, so I appreciate that this is quite a challenge for me!

So, I have access to a Ubuntu 11 box which is currently hosting a Django v0.97 site. I need to move this site to a CentOS5 (Python v2.4.3) box. There isn't really anything to upset on the CentOS box so I am clear to uninstall and shuffle stuff around. I have ran a full 'yum update' on CentOS.

I have obviously started by transferring the ubuntu:/var/www/hayley folder to centos:/var/www/hayley and setting up Apache.

Googling has had me ensure the following are installed:

yum install gcc gcc-c++

yum install zlib-devel

yum install subversion

yum install MySQL-python python-devel

yum install mod_python

yum install httpd-devel

yum install memcached

yum install mysql-server

yum install python-devel mysql-devel

yum install python-setuptools

http://www.psycopg.org/psycopg/tarballs/PSYCOPG-2-4/psycopg2-2.4.5.tar.gz

http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz

easy_install PIL

easy_install sorl-thumbnail

I have ran the installer for Django, found in /var/www/hayley/django-nfa.

I have encountered a tonne of issues so far, which I have been resolving with the aid of Google, but I feel I am still a long way off getting this to work. In it's current state, if I attempt to access the site, I receive an 'internal server error' [500], and my httpd log shows:

"ImproperlyConfigured: Error while importing URLconf 'hayley.urls': No module named sorl"

At this point, I would like to ask:

1) Are there are any obvious packages I am missing?

2) Even though I believe I have installed sorl-thumbnail, the above error obviously indicates an issue. Can someone please suggest where to look in order to address it?

3) Given this type of migration, is there anything obvious which I need to account for?

Thanks all!

Elliot

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/SbBegpsGOTUJ.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Bill Freeman]

A bit of generic advice:

Be sure that you know which python is running your stuff: mod_wsgi,
and IIRC mod_python (if the site really uses it) are bound to a
specific python interpreter. It may or may not be the one where you
installed sorl-thumbnail. One question is whether the:

python manage.py shell

will start. If that works, runserver (the development server will
probably work (I'm guessing that you've been testing via Apache). If
so, then use the shell to pretty print sys.path, to find out where
that configuration is finding stuff:

from pprint import pprint
import sys
pprint(sys.path)

You can also write a trivial WSGI "application" (it's just a function)
that creates a text/plain response giving the same information for
that environment. You can also capture sys.version to confirm that
both pythons are, say, a 2.7.x or not.

If both pythons are compatible versions (not, say, a 2.6 and a 2.7),
you may be able to fix things with the python-path argument to the
WSGIDaemonProcess directive (specific to the daemon process group) or
more globally by using a WSGIPythonHome or WSGIPythonPath directive.
But it is also possible to install stuff in the python that mod_wsgi
is using be default, and to arrange for any manage.py actions you need
to run with that python.

Bill

[Elliot]

Hi guys, thank you sincerely for your feedback.

As far as I know there is just the one instance of python installed:

"

>>> print sys.path

['', '/usr/lib/python2.4/site-packages/PIL-1.1.7-py2.4-linux-i686.egg', '/usr/lib/python2.4/site-packages/sorl_thumbnail-11.12-py2.4.egg', '/usr/lib/python24.zip', '/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2', '/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload', '/usr/lib/python2.4/site-packages', '/usr/lib/python2.4/site-packages/Numeric', '/usr/lib/python2.4/site-packages/gtk-2.0']

[root@svr-h001463 hayley]# whereis python

python: /usr/bin/python /usr/bin/python2.4 /usr/lib/python2.4 /usr/include/python2.4 /usr/share/man/man1/python.1.gz

[root@svr-h001463 hayley]# cd /usr/lib

[root@svr-h001463 lib]# ls -d */ | grep "py"

pygtk/

python2.4/

"

If I try 'python manage.py shell':

"

[root@svr-h001463 hayley]# python manage.py shell

Traceback (most recent call last):

  File "manage.py", line 11, in ?

    execute_manager(settings)

  File "/usr/lib/python2.4/site-packages/django/core/management/__init__.py", line 301, in execute_manager

    utility.execute()

  File "/usr/lib/python2.4/site-packages/django/core/management/__init__.py", line 248, in execute

    self.fetch_command(subcommand).run_from_argv(self.argv)

  File "/usr/lib/python2.4/site-packages/django/core/management/base.py", line 77, in run_from_argv

    self.execute(*args, **options.__dict__)

  File "/usr/lib/python2.4/site-packages/django/core/management/base.py", line 86, in execute

    translation.activate('en-us')

  File "/usr/lib/python2.4/site-packages/django/utils/translation/__init__.py", line 73, in activate

    return real_activate(language)

  File "/usr/lib/python2.4/site-packages/django/utils/translation/__init__.py", line 43, in delayed_loader

    return g['real_%s' % caller](*args, **kwargs)

  File "/usr/lib/python2.4/site-packages/django/utils/translation/trans_real.py", line 220, in activate

    _active[currentThread()] = translation(language)

  File "/usr/lib/python2.4/site-packages/django/utils/translation/trans_real.py", line 209, in translation

    default_translation = _fetch(settings.LANGUAGE_CODE)

  File "/usr/lib/python2.4/site-packages/django/utils/translation/trans_real.py", line 192, in _fetch

    app = getattr(__import__(appname[:p], {}, {}, [appname[p+1:]]), appname[p+1:])

  File "/usr/lib/python2.4/site-packages/sorl_thumbnail-11.12-py2.4.egg/sorl/thumbnail/__init__.py", line 1, in ?

    from sorl.thumbnail.fields import ImageField

  File "/usr/lib/python2.4/site-packages/sorl_thumbnail-11.12-py2.4.egg/sorl/thumbnail/fields.py", line 61

    with open(data.temporary_file_path(), 'rb') as fp:

            ^

SyntaxError: invalid syntax

"

It's going to take me a while to understand all that. This is likely the first time I've had to dig around python.

I'll follow up on your suggestions, but in the meantime, if any of the above throws any more light on the issue from your perspective, further comments would be appreciated :)

Thank you!

Elliot

[Cal Leeming [Simplicity Media Ltd]]

The paste you gave us is python 2.4, very old!

My guess is that your old server is 2.4, and your new one is 2.6/2.7 - or the other way around - that would explain the weirdness.

On your new/old server, paste us the result of just typing 'python' on its own.

Cal

--

You received this message because you are subscribed to the Google Groups "Django users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/Pe87o1sLPq4J.

[Tom Evans]

On Wed, Oct 3, 2012 at 4:31 PM, Elliot <elliot....@hayley-group.com> wrote:

"with foo as bar" is a python 2.5 concept, so this version of
django-sorl is not compatible with 2.4. They almost certainly changed
it due to django itself no longer supporting python 2.4 after version
1.3.

When you installed the packages on the new box, I suspect
(particularly with packages you installed using easy_install) that you
have installed newer versions of those packages than existed on the
older box.

If you can start from scratch (!), I would start using the tool 'pip'
to discover what packages and versions you have on the old box, and
install exactly those versions on the new box. You may have to install
pip..

With pip installed, run "pip freeze" on the old box, which will output
a list of all packages available in the current environment. On the
new box, you can then run on the new box "pip install
sorl-thumbnail==3.2.5", or whatever version you require.

You might also want to look up virtualenv, which allows you to isolate
python packages per application, allowing different environments to
install different versions of the same package, and pip requirement
files, which allow you to specify all libraries that an application
needs to run. Combining the two gives you a simple file that defines
all the dependencies required by an app, and a tool that can take that
file and install them all into a disposable environment for the app -
in effect, consistent 1 step setup.

Cheers

Tom

[Elliot]

Hi all,

Thank you once again for your insight and feedback.

I had gathered that Python2.4 is pretty old, but I guess I expected it on the CentOS5 box. This is the 'latest' as far as the CentOS official repos are concerned. Additionally, according to the Django v0.97 'INSTALL' readme, it's compatible with Python v2.3 or greater.

Also, a bit more background which might help:

• This 'hayley' website was originally created about 5 or 6 years ago by a third-party, and was built with Django v0.97 on an unknown platform (and unknown version of Python but I assume 2.3 or 2.4).
  
• It was then moved temporarily to a Unbuntu11 box (where it is now), by another third party. It appears to have Python 2.6 and 2.7 installed. Running python from the command line launches v2.7.1. I have remote SSH root access to this box, but it's not my property and, being a production server, I don't want to mess it up!
  
• I have now been asked to investigate moving it to an in-house server. As I am more familiar with CentOS than any other distro, and we had a CentOS5 server sitting around doing little else than hosting some samba shares, I decided to to try to port it here.
  

I have checked the Django site, and have noted that Django v1.4.1 seems the latest, but I have also read that migrating a v0.97 Django project to Django v1.4.1 isn't straight-forward. I thought I could cut down on the hassle by staying with Django v0.97(!). I also assumed that with Django v0.97 being old, the older version of Python would be more appropriate/compatible.

The suggestion that the version of sorl I am using is incompatible with python2.4 is a good call. I am going to look into uninstalling this and finding an older version. Failing that I will try and upgrade Python2.4 to v.27 on the CentOS box from an alternate repo.

Cheers guys :)

Elliot

[Bill Freeman]

v0.97 of Django is compatible with python 2.4, but, as noted above the
version of sorl (which is not part of the Django that makes that
promise, but an external add-on) is not.

You have a few choices:

1. You can tar (or zip) up the stuff in site-packages/sorl on the old
box, to move to the new box. You may have to get rid of the .pyc
files. You will probably have to get rid of any .pyo and .pyd files,
and then what has been copied is probably not enough to regenerate
them (unlike the .pyc files).

2. Better would be if you could find an egg or tar file for the
version you had been running, then install that in place of the sorl
that you have.

3. You could fix the code in question:

with open(data.temporary_file_path(), 'rb') as fp:

is roughly equivalent to:

try:
fp = open(data.temporary_file_path(), 'rb')
<The code that was "inside" the "with"
finally:
fp.close()

It should (sing the file is opened for reading, and not writing) even
work without
the try-finally-close, but could consume extra memory (on average).
But there may be more stuff.

4. While it is extra work, it is easy to install more than one version
of python on, especially, a linux box. There may be a 2.5 or 2.6
package for CentOS5 somewhere. Building python from source is not
hard, but has pitfalls. The major trick to know about is that you
don't want to say "make install" at the end, but rather "make
altinstall" (documented in the python build instructions). That
performs all the same steps, except it does not link the name "python"
to the executable. Typing "python" still will get you (and all the
system management scripts that use python on a Red Hat derivative OS)
version 2.4. You have to type, for example "python2.6" to use the
other python.

Sadly, building python would mean that you also have to build
mod_wsgi, and now we are getting pretty complex, if you haven't done
that sort of things before.

By the way, you probably don't want to go all the way to python 2.7 if
you're trying to run very old python code. 2.7 introduces some
backwards incompatibilities as part of trying to persuade folks to go
to python 3.x. The one that I've hit is the fact that "as" is now a
keyword, and can't be used as a variable name ("As" can, however),
which was how it was used in a third party library that I needed.

5. You could bump to CentOS 6, and port the site to modern Django
(and other package) versions. That may sound like a lot of work, but
I suspect that it's comparable to the effort in all above but #2, and
#2 only works if you can find the package, and if there aren't other
problems with other packages. And you get additional perks, including
better maintainability, with updating to modern stuff.

Bill

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/django-users/-/FAlQ1AoMD9kJ.