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
On Thu, Oct 4, 2012 at 4:50 AM, Elliot <elliot.john...@hayley-group.com> wrote:
> 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
>
> On Wednesday, October 3, 2012 4:57:49 PM UTC+1, Tom Evans wrote:
>>
>> On Wed, Oct 3, 2012 at 4:31 PM, Elliot <elliot....@hayley-group.com>
>> wrote:
>> > 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
>> > "
>>
>> "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
>
> --
> 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.
>
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
