Looking for a good Python environment

[Eric S. Johansson]

ram.rachum at gail.com wrote:
> Hey, I'm looking for a good Python environment. That is, at least an editor
> and a debugger, and it should run on Windows. Does anyone have any idea?

I've been looking for the equivalent although I want the IDE to run on Windows
and to be able to edit/debug/bzr files on a remote system (linux in VM or remote 
physical hardware).

Solutions that I've explored are:

Network filesystems (Samba, NFS)
Emacs plus tramp
eclipse plus remote file access
remote system IDE, local display with X11
local editor plus unison

Here's how they failed:

Network filesystems always fail because they get ownership and permissions 
wrong.  No matter what you set the mapping to, it's almost always wrong for some 
part of the system.  It's made worse because setup .py does not make it easy to 
force permissions and ownership to what you want them to be (afaik).   this 
forces the use of an ad hoc script to enforce permissions and ownership after 
running setup.py.

using this configuration, it is possible to hibernate your Windows machine but 
only if you manually restart your remote filesystem connections before trying to 
do anything with your IDE.

Emacs plus tramp is the best solution so far albeit somewhat fragile.  It's 
moderately difficult to jump into the right point in the filesystem although 
this may be an artifact of trying to use speech recognition for this task. 
another annoying problem is forcing Emacs to use UNIX format text files.  I know 
I just need to RTF but I haven't gotten around to it yet.

Emacs plus tramp is also the easiest to hibernate as it does not use persistent 
connections to remote machine but if the remote host isn't available when you 
try to access a file via recentf, you lose the reference to the file and need to 
type/speak the path in again.

Eclipse has been an unmitigated disaster for me.  It's fat, it's heavy, it 
pushes all of my other applications out of virtual memory and then I need to 
wait 10s of seconds when I switch.  I can't figure out which components of the 
bag of parts I need and easy eclipse is too old to use the remote file system 
access extension.  blech.

Using X11 for local display is great if the remote machine is local and you're 
not paging out to virtual memory.  most common problem is that the local X11 
display loses track of local Windows and you end up with this graphic ink blot 
on the screen that never quite goes away until you restart X11 and all the other 
applications through it.

with the X11 solution,  you cannot hibernate your host machine because the 
persistent connections break and cannot be restarted.

local editor plus unison sort of, kind of works.  Yes, you can edit all your 
files and replicate them on the target machine.  Ownership and permissions are 
broken.  There is a problem with UNIX versus DOS file format but once you force 
the editor to do the right thing, the format is right on the remote side.  It's 
clumsy but it does have the advantage that if you make changes on the remote 
system when debugging, those changes are replicated back on your editing house.

As for debugging, personally, I just use winpdb everywhere and just suffer with 
bad X11 connections.

One additional factor raised by split machine operations is how do you organize 
your files?  Do you have different repositories on different machines or do you 
have a single repository on your editing host and look to some form of 
replication for updates across one or more machines?

it's an interesting set of problems.  Today, I just muddle along as I don't 
really see a good solution.  I'm hoping I'll be proven wrong and find a solution 
that will make my life easier someday.

-- 
Speech-recognition in use.  It makes mistakes, I correct some.