So far, the portability has been very useful. I dropped the whole thing onto my work computer in a couple mins. On the whole, saved me a lot of hassle.
The main tweaks I've made so far:
1. Environment variables. For Java you need JAVA_HOME, etc. Typically, the installer creates system vars, so you could manually do this, but I do something even better: create small shell files that sets it as a temporary user var. Then you add a call to this file anywhere you need it. For example, instead of executing Eclipse directly, create a shell file that first calls the file to set the vars, then executes Eclipse. The beauty is that you can run multiple environments at the same time. For example, because you're using user vars and not using system vars, you can run your app with JAVA_HOME pointed to 1.5 version, and then run it again with JAVA_HOME pointed to 1.6.
You need versions for each OS you run on, but that is pretty basic shell writing.
2. Registration settings. The installer typically sets the extension to automatically invoke the executable; i.e., .rb files can be run directly, without pre-pending with "ruby". Minor issue to me, though you could easily write a script to registers the association wherever you are, but you might compromise your ability to run multiple environments.
A bigger deal is that in Windows, you lose right-click shortcuts. In some cases, like 7zip and Vim, it's an inconvenience, but some others, like gitTortoise, you're out of luck. No gitTortoise for you, just the git command line or built-in UI. I do like Tortoise from my SVN days, so you could go with a mixed strategy: install locally where you can, but keep the portable version as part of the env in case you find yourself in a situation where you can't install an app.
3. gVim settings. One of the pleasant surprises with Vim is that everything seems to be configurable, and thus it supports every feature I've thrown at it. Here's the ones I've added to my default settings, critical to me for usability:
colorscheme murphy " you can get very granular, but I just chose one of the included themes
set number " turn on line numbers for all doc types
set expandtab " convert tabs into spaces
set tabstop=2 " set tab width
set shiftwidth=2 " indentation
set lines=60 " width of Vim window
set columns=80 " height of Vim window
set directory=..\..\temp " location of backup files
set backupdir=..\..\temp " location of temporary files
vnoremap < " de-indentation of highlighted text block using <
vnoremap > >gv " indentation of highlighted text block using >
4. network drives. If you keep the portable env on a local drive, you won't have the problem discussed here. Because you don't ever know whether you'll be dropping the env on the C: or the J:, on the root or in "/dev/my env/dir/subdir", you have to use relative paths and directory variables when. So far, this has never been insurmountable, but the most difficult challenge was when I dropped the env on a Windows network directory.
If you run a .bat file on a network drive, it can't change directory to there, so it defaults to the local Windows system directory, and all your relative paths are messed up. Here's some
good documentation on it, but the quick answer was using
pushd "%~dp0" at the beginning of the batch file. This creates a drive letter and points to the dir that you're executing the batch file in. Now all your relatives paths are intact.
-----
It might seem that getting the portable environment right sucks up a bunch of time. That's true, but actually whenever you want a good personalized environment, you spend quite a bit of time installing and configuring your tools. The great part about a portable environment is that you won't have to do it again!
