[EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
