Python error interpretation

[CLIFFORD ILKAY]

Hal Burgiss wrote:
> Well, thanks. I am trying to avoid a clean re-install since its just
> starting to be used now, and all the custom stuff (firewall, backups,
> Apache, etc) we need to do has already been done. Ironically, that
> prompted me to want to automate that customization process and why I
> was playing with bzr to start with.
> 
> Overall, I love apt, but occasionally its really oddly difficult to
> start with a clean slate.
> 
> I may do an apt purge, and then physical hunt and destroy for python
> pieces.

The situation you've described illustrates the problems of ad-hoc system
administration and why using configuration management tools like
cfengine, puppet, or bcfg are desirable. You should never be in a
position where the cost of doing a clean install is so high that you
avoid it. Whether you like it or not, eventually you'll be forced to do
one anyway when a hard disk fails so you should always be in a position
to be able to recover from bare metal to the exact configuration you had
before inside an hour. I think you've already recognized this need when
you talk about automating the customization process.

Kickstart/preseed installations, Cobbler, virtualization, LVM, cfengine,
and Subversion are all tools we use to automate system installation,
configuration management, and recovery.

By the way, removing/installing Python may not solve your problem. You
should be able to run any number of versions of Python and Python
packages on your system, if you understand how to set PYTHONPATH. For
instance, sometimes we need to deploy a Django application with a
specific version of Django that is different than the global one that
we've deployed in site-packages. In that case, we just check out the
specific version of Django into some sensible place, like the directory
containing the Django application, and adjust PYTHONPATH accordingly.
Here is a real example of a shell script from one of our projects.

cilkay at saturn:~/projects/ccf$ cat paths.sh
export
PYTHONPATH=/home/cilkay/projects/ccf/django_0.96.3:/home/cilkay/projects/ccf/:/home/cilkay/projects/ccf/lib/

In that project, for various reasons that aren't germane to this
discussion, we have a dependency on Django 0.96.3 as opposed to the
latest official release 1.0.2, which is available globally by virtue of
being in site-packages. We override the global default by running
"source paths.sh" in the shell before we run the Django development
server. We also put the ccf project and some utility libraries into the
PYTHONPATH so that we can import and use the modules within those
directories without problems.
-- 
Regards,

Clifford Ilkay
Dinamis
1419-3266 Yonge St.
Toronto, ON
Canada  M4N 3P6

<http://dinamis.com>
+1 416-410-3326
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3286 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20090315/5e7fde18/attachment.bin>