Daily usecases for a torchlight in a geek's life

Recently I purchased a Fenix PD-32 torchlight and have been getting endless questions about the whys and the uses I have for my torchlight, especially when people see it peeking out ever so slightly from my pocket, so in order to put these questions or part of them to rest let me list down here the use cases my torch sees throughout a typical day.

The Fenix range of EDC (Every Day Carry) torchlights are not your typical torchlights. They are of higher end quality and are built tougher than the free torchlight that comes together in the package of batteries you bought at your local mini mart. 

1. As a "lantern" during those late nights when you family is asleep and you are still in owl mode. Scenario: The room is dark and you don't really want to switch on any lights so as not to wake up your wife and your baby when you are groping around trying to look for that damn thumbdrive which you copied your movie into. Trust me during this time a torch is invaluable.
2. During the day when you are driving around suddenly you want to check what is that rank coming out of your car's AC system. Nothing works better than a good torch in these conditions. Great for checking if your car is okay too after you scraped through a particularly bad road bump.
3. The torch is built with higher end steel, with higher end material. In some really boring long meetings, I just want something something warm and non threatening to hold and play around in my hands. I tried using a folding knife for this end but let's just say the outcome of the meeting not to mention the look of the other participants of the meeting was not that favorable. 
4. As a source of light instead of using your iPhone during the night. Come on, using your phone as the light source is so-un-geek and yesterday. Besides, moving around my house during the night with the Fenix makes me feel like a badass cat burglar or a cop investigating a crime scene. You might have to do a bit of explaining though if your neighbors happen to think the same thing when they see the light of your torch.
5. You are not a fully qualified geek when you did not have to go into a dark server room after a blackout to restart back servers. The ideal server room is fully lit and after the electricity is restored you should never have to use a torch, but then ideal case ? In this world ? Under the floor paneling ? Get a torch!
6. Get the right kind of torch, like in my case and you give yourself reason to get more geeky hardware like a lithium battery charger! Great fun! More stuff to hide away from the Missus or SWMBO.
7. Great way to impress other geeks by submerging your torch in water or throwing it 1 meter away only to reveal it's unscathed. 
8. I run barefoot at night and sometimes the wee mornings and while I do not really encounter broken glass on the road all the time, the ones that I do see are usually the sharp brown type which is nearly invisible in some of the times I run. Little torch has saved my soles on numerous such occasions.

Kate's python plugins really needs some package love!

I have been trying out Kate's Pate or Kate's Python Plugins on various Linux distributions and my finding is this. Most of them don't work right out of the box. Pate used to be an external plugin that you had to install into Kate but now is part of Kate's default plugins.

This is kind of a shame to me as when the plugins, work right, they are really great and of all I have seen has got great potential. The problem here is that none of them work right out of the box. I only managed to install and get one installation right on an OpenSuSE box.

Try to follow along the origin story of pate (if you can!)

The plugins that can be used in KDE 3 can be found here: http://paul.giannaros.org/pate/. The latest and greatest, which means that can be used with KDE 4 can be found here: https://github.com/pag/pate, but then from the looks of it the last change in that repo is quite sometime ago. It says that the project was passed down to kate-editor about 6 months ago.  Well increasing the count of developers from one to twelve is always a good thing. This to me is a positive development for Kate's future.

My advise is either you try the source or stick with your distro's package management. Try not to mix the two unless your day has really been slow and you are desperate for some time tinkering around with package resolutions on your box. The plugins themselves has a feeling of still being under heavy development, which is not evident from the two links above. Rather what I found that was nearer to the true source is here: http://kate-editor.org/get-it/. I think that absorbing the python plugins to be the default set of plugins that comes with Kate is a good move and ensures the future of the plugins, just that we need some good packages to ensure that the plugins themselves are showcased and represented correctly to users. Of the two packages I tried: LinuxMint and Sabayon, both were missing dependencies which I have already reported it. On my trusty Sabayon Pate would not even load because of mismatch of versions of somekind related to sip. 


The allure for me for considering Kate for an IDE is that it already comes with KDE, which I use from time to time so there is no additional bloat to put on top of KDE which is is nice so I hope that they get this right. The list of features to come with Kate that I use daily are:

1. Linting (pep8, pyflakes and pylint). Here I wished that I got a list of clickable pep violations rather than a pop up window that would disappear with time. A bit clunky but at least it's there without me having to do some extra tinkering. 
2. Project (svn and git integration but with some manual tinkering. Coult not get this to work though)
3. A basic Python console. This comes as a "pop up" window. If it was integrated or inline it would have been superb but then having a console itself is great. 
4. Snippet support and easy creation of snippet.
5. Some great code editing functionality such as code navigation and their likes.  
6. Vi-mode keymap.

Another one thing that I felt wanting since I have been too spoilt by PyCharm and Sublime is the all powerful alt-p in Sublime and the ctrl-alt-a in PyCharm. Wished that there was such a thing in Kate. Would have really cut short the time trying to explore around in the GUI which is actually quite a substantial time since it has grown by leaps and bounds. I had a good time looking for some configuration items and hunting around on the UI's menu system really made me hanker for PyCharm's and Sublime's superb all seeing-eye key.

Just as an update, I managed to get the full version working on Mint 15 but I had to use backports. I was happy to get it working so that at least I would be using and judging the plugins itself instead of judging the installation and configuration of the plugins. There are a few things apparent when I was using Kate for my daily editing jobs. One looking for stuff without the all seeing eye is a chore. The other is, the fact that I got to play around with external tools for viewing repository history and checking in is a definite pain and a minus against it. Well, you can look at it two ways. One way is Kate is a really good editor and the other it is really not as accomplished as an "Integrated" Development Environment for Python. It's all really there, just that probably some more thought has got to be put in to redesign some of the screens to change the workflows to be less clunky.

References:

Bug Report Sabayon: http://bugs.sabayon.org/show_bug.cgi?id=4447
Linux Mint bug report: https://bugs.launchpad.net/linuxmint/+bug/1239506

Deployment woes

We are still having deployment woes here where we deploy our applications on to live servers. What really irks me is that these errors are very amateurish and keeps on giving our whole team a bad image. This is a waste as clients keeps on focusing on what is wrong instead of what was done right. This also puts them into a fault finding mode which is not advantageous to adoption of new functionality.

What do I mean by "Silly mistakes" ? When I say this I mean things like major services not enabled after server upgrades / deployment. Some errors I have found are:

• Mis configured wsgi files usually something to do with paths or virtualenvs
• Core services that error-ed out usually web servers or cron server. Our application depends largely on scheduled jobs and cron jobs erroring out and not running can prove disastrous.
• Wrong people seeing the wrong things on the server or just some silly test strings appearing on the live system. 

This kind of errors, it's very hard to recover and cover or explain as it really looks amateurish and as though we don't know what we are doing. Depending on our own people to eye ball the application after upgrade is not workable for simple reason, no one can ever take leave and people tend to make mistakes. The other challenge is of course to find the mid way point between resources that are stretched to the breaking point and putting in some fashion of testing as a stop gap for this kind of silly mistakes. I still feel that asking developers to check on the work that they have been working day in day out everyday for most of the week or month is not really a good idea. I am just constantly surprised how our clients use our application, normally just something I have never considered using it that way.

I saw that we had really good notification checking and we had tests. We had good selenium tests and good nagios scripts. I thought about incorporating our nagios scripts into our deployment script where the deployment script would call the nagios scripts to check our core services. That would also give us a somewhat basic check script for our application that would give us a head start with minimal effort. Our notifications scripts were actually customized scripts written for Nagios. If we were to run them after the upgrade / deployment of our sites it could then warn or tell us if we fudged up and certain services were indeed dead.

On the selenium side, we could abstract some basic tests from our existing scripts to run after an upgrade or deployment is done. These are just a subset of the full test and should just try the basic functionality of the components comprised in the whole application.

Ideally the collection of behavior about a certain upgrade / deployment should come from the project team or the stake holders in the form of BDD scripts. This flies against what I have been told about running my tests on live systems but then having your clients doubt your system as being buggy because you failed to check your application at the most basic level is just not fun and does not foster good faith in your system nor does it help to solidify job security. I am still at the drawing board for this but then it would work something like this. The post installation step would require us to run either a selenium test or any other black box type testing based on collected BDD scripts written based on core or important functionality that should be deployed in a particular version of deployment or installation.

At last and in no way is this a conclusion, we have decided to go the route where we have some pre-flight tests before we release our deployment out into the wild. These pre-flight tests also should contain BDD scripts that are passed down to us by stake holders in the project.  The other thing that I found is, as much as we want convenience security to live servers should be locked down to as few people have administrator rights as possible and as much as it pains to tune ACL for every specific action, it pays in the end when you want to track who did what to screw up another live server deployment. 

Review of the Xtar XP4 charger

Besides tinkering around with Python and system stuff as evident from the bigger title of this blog, I am also a certified battery charger nut. Just the technology behind battery chargers and the types of them out there totally fascinates me. Recently, I was offered the chance to review one of the new battery chargers from Xtar called the XP4. Why is this battery charger special ? Well to fully appreciate how this charger is special firstly you got to understand that batteries are made out of different compositions, the two main camps currently used are the Nickle and Lithium camps. Your typical rechargeable AA/AAA you find in the market nowadays are usually of the Nickle camp while your phone and laptops usually uses Lithium batteries.  Each camps' batteries have their own special way they like to be charged and in a lot of ways are different.

Because of this difference, making a charger that can automatically sense the type of battery put into it and charge it just the way it likes to be charge proves to be a challenge not many chargers currently in the market can answer currently. Currently the majority of chargers in the market are what you would call "dumb chargers" as in their time based, where they will charge up until a certain point then switch off. Put in a battery that is 80% full vs 10% and it will still "dumbly" charge it for 5 hours then switch off. Not too efficient or smart.

Before this, there are actually chargers being sold that can charge both of them but these class of chargers are what people call "Hobby Chargers" because they were mainly used to charge battery packs used for RC toys. This also meant that if you were just looking for a charger with battery trays built in to charge 'normal' batteries, you are better off looking somewhere else. How these chargers handled dual chemistry is by having the user choose the type of battery that they are going to charge before hand.

The XP4 is a dual chemistry charger new in the market. It can charge NiCD, NiCd and Lithium batteries. I have tried charging mostly NiMh batteries on it as I do not really own any Lithium batteries (well not yet). So, far from what I can see, the charger works flawlessly. It has four independant channels. What this means is that each channel works by itself like a self contained battery charger and can work individually without being effected by the other channels. Some battery chargers out in the market now have paired channels. That means that batteries must be charged in pairs as the underlying circuitry pairs up the channels.

I was happy and excited to review this charger as personally I am happy that Chinese electronics are finally starting to come out on their own with their own brands rather than just acting as the behind-the-scenes manufacturer for other companies. Xtar or Xtarlight is one of the more reputable companies based in Hong Kong.

This charger will also mark Xtar's first batch of foray (the other charger being XP1) into the NiMh/NiCd scene.  More and more you see these new Chinese companies coming out with their own brand of chargers which have no counterpart on the European which are at the same time affordable. While for now buying and using these chargers for now can be like a walk on the wild side as in the huge mixing bowl there are good as well as not so reputable manufacturers, a few good companies like Xtarlight has emerged that produce good and stable hardware. If the chargers produced by them have good functionality coupled with good safety features, I say all the more power to them! I am impartial to who really produces them, as long as it's a good product, though traditionally Chinese / Asian manufacturers have not really been known to put consumer safety high up in their list as they do not have as stringent as the standards enforced on them compared to their Western counterparts.

On to the review....

My initial views on the charger:

Construction (5/5):

 

 

This charger is code named "Panzer" and in my opinion aptly too as the construction feels solid just like a tank. I kept on getting the model of this charger wrong initially because of their significant lineup. My advice ? Just call the frigging thing Xtar Panzer! Nice ring to it and easy to remember.

The charger even comes with it's own verification code to ensure that the charger is genuine. It works albeit just a little too spartan or basic to be truly impressive or memorable.

The springs feel and work well without much hint of needing any lubrication. I based this finding comparing with other chargers with springs which normally need a touch of lubrication to work normally. The case also feels solid and surprisingly does not feel light or 'cheap'. I would say on this end, I am happy that Xtar did not spare when it came to materials to build the charger, even though the cost of them putting everything into the charger did show on the box material. The charger has got a nice solid feel to it. While I would have liked to have a digital display to show charging progress of batteries, for an initial effort from Xtar, this is sufficient. Here is a picture of the charger with the 4 bays in question. These chargers because of the protrusion on the metal contact will work with flat top batteries too. Initially, I was not used to the way the battery fit into the bays but after a few days I found it to be second nature.  I guess the initial issue I had with it was because this is my first unit that uses a spring loaded.

Performance (4/5):

Some confusion I had initially was about the temperature sensor on the charger. On the manual it states that the charger's "operating temperature" for NiMh batteries was about 40 Celcius. I mistaken this for that the device contained some kind of temperature sensor but as pointed out by xtar representative this is not true. One thing I must note here is that the representative from Xtar must be given a point here because of their exemplary service. Every question that I had ranging from when the charger is going to be released right up to if the charger contained any temperature sensors was answered courteously and in a timely manner. Back to the charger, while it did not have a temperature sensor, none of the batteries that I charged on it became anything beyond warm because I suspect that it's heat dissipation is really good. I guess what it really meant by "operating temperature" really means what normal temperature the charger will be operating at when charging NiMh batteries.

I don't really have any of those fancy man toys to measure heat via thermal images  beyond a child thermometer so you have got to take my word without backing proof here. Normally for NiMh battery chargers, currently in the market there are roughly 3 ways to terminate charge on a battery and switch to trickle charge:

1. dv Change in voltage as in a voltage dip after being fully charged.
2. dT temperature controlled as in the cases where the battery becomes overly warm. 
3. Time controlled. This is the so called "dumb charger".

Ideally a NiMh charger should have the ability to do 1 and 2, just in the case if the voltage detection fails, then at least the possibility of the batteries melting in the charger can be avoided. The best case scenario is if a charger can do all three. This charger can do one of them and in most cases do it rather well so I guess it's acceptable, just that the "operating temperature" might be confusing and bring certain people for a loop.

Nearly all of the charging scenario, my findings are all based on the 0.5A charging settings as running on the 0.25A settings, some of the charging could not be terminated and was running indefinitely. After numerous exchanges on the forums namely candlepower forums, I was informed that 0.25A is way too low and most chargers would miss the termination. I take away 0.5 point from the charger here as it allows the user to pick the 0.25A charge setting although it might have problems terminating the charge on that setting, I mean the charger itself should not allow batteries to be charged at that setting if there potentially would be a problem terminating the charge at that setting.

Charging batteries(3/5)

Besides charging batteries of different chemistries namely Lithium and NiMh batteries this charger also come with a few other functions:

• Discharge / Charge cycle for NiMh
• Discharge of Lithium via USB to charge mobile devices (only for batteries loaded into Bay 4 of the charger)

** For all of the times I did my evaluation of these functionality I wished that I had a fancy schmancy multimeter to capture all of the data coming from charger. Alas, I don't, I guess next time or if someone sends it to me to be evaluated. 

Here is what I thought of them:

Charging Lithium bats

Since I did not really have any Lithium batteries, in order to be complete I decided to go out there and finally get myself a torchlight. I settled on the PD32 out of recommendation which came with a Lithium battery.

Charging Lithium plus NiMh

Both of the batteries terminated fine and I had no issues here, one improvement I can see here is if in future editions of this charger the basic lcd display in the VP1 can be incorporated somehow into this charger it would be great. 

USB discharge function 

I tried using the USB discharge function to power up my Samsung S3 and it seems to work as advertised, the only issue I seemed to have run into is that the connector of the USB seems a bit loose (it could very well have been my own cable as well, so I won't fault the charger for this) and it disrupted the charging multiple times. Charging is acceptable and not anything memorable. The only  thing that would have liked or I found lacking is that if only the USB function would work also if connected to a AC source then it would be superb. Assuming that the unit will only be used as a powerbank seems to be a mis-step on the construction of the unit.  Also, if this unit was meant to be used as a powerbank it would be nice if batteries of different chemistries could be used instead of just Lithiums. The other thing is that the way that the unit holds the battery should be more secure if you really want to use the USB discharge function to charge up your HP or other mobile devices. Below is shown the USB section of the charger.

Discharge and Charge

The discharge and charge function is another function offered by XP4 which differentiates it from most chargers in the market now. There aren't many at this price range that does that.  The only compliant I have here is that it this cycle takes a long time as it does not allow you to choose the discharge current. The option of the charge current only takes effect during the charging stage.

Conclusion

Likes

- The construction of the charger is great and feels solid
- The charging works (at 0.5A) settings with NiMh and Liion batteries that I tried.

So-so

- The verification code on the site seems a little too basic to be impressive.
- You cannot choose the discharge current in the discharge-charge or the refresh function.
- USB function only works with Lithium batteries and do not work with NiMh batteries.
- Lacking the LCD display that came with VP1.

Dislikes

- There are no temperature sensor which can do dT based termination
- Charging at 0.25A charging is very spotty. Should not have allowed charging at this setting in my opinion
- You cannot use the USB when the AC is connected to the device.

As I see it now, the charger seems to be a good initial effort of Xtar foraying into the NiMh charging sphere. Where does it fit ? Well I have arguably the most advanced NiMh system out there: NC2500 from SkyRC but where I see Xtar's XP4 shining is the convenience of just having one charger that can do all sorts of charging. If I just want to dump my batteries irrespective of type into it and not want anymore information beyond just when it's charging and when it's done XP4 fits the bill perfectly. Look for this charger if you already know something about your batteries and just want something that charges and works without you having to do a lot of settings before it starts charging. While it is not perfect, I am happy with this initial effort and do hope that they continue to improve on this charger. I am looking forward to see an improved version of this in the future.

Also, I don't think that this review is complete without at least a mention of the great PR that Xtar has. The person that communicated with me about this charger was responsive and promptly answered all of my questions. Although this was my first time getting a review set from them I was very impressed with they way they treated me. This is one thing that the company has right and judging from their FB page, they got the community around them happy too. 

You can probably find a good deal here:

XTAR XP4 Panzer Ni-MH/Li-ion Charger with USB Charging Port for Cell Phone & Car Adaptor



 

Emacs for Python Development aka as an IDE Part 1

I have been using Emacs for Python development for about 3 months now and I must say that it's not so bad even rivaling PyCharm in a few departments especially how it handles text around in a few ways is superior IMO.

I use Emacs with ergoemacs and I have elpa and melpa enabled for installing packages. What is ergoemacs ? For those of you who feel that Emacs uses too much of the CTRL plus other keys combination, ergoemacs will prove to be a respite as it remaps the default keys of Emacs to what the author felt to be keys more friendly to those having RSI hence the name ergo-emacs.

What I found initially like any hardened VI user is moving around is a real hassle and kept on pounding on the wrong keys. After a while though, I began to get proficient at it and now the tables have flipped and I feel totally inadequate in vim, pressing the wrong keys all the time. I appreciate a few things about Emacs. One is that when I run it I am already inside of insert/edit mode.... no need to press one more key for me to be in edit mode. The other thing is, out of the box, I found that I had less to install to the editor up to snuff to use as an everyday editor. Of course, I also love alt-x or in ergo's case alt-a. All I had to do was get flycheck, which is an on the fly pep8 error checking for Emacs to work. Another thing is the speed in which emacs can start up using the "--daemon" argument. The only thing is I still could not figure out how to the daemon as an init script on my box. How I do it now is I will tuck the daemon away in a tmux session during start up.

Below, is a screenie with my terminal running emacs in it's full glory ...

The majority of the time I spent was not tinkering on my editor (which I sometimes felt using Vim) rather I spent it mostly learning up the new keymaps. I am still no emacs expert by any stretch of the imagination, but I feel myself improving faster compared to Vim. Currently believe it or not my only problem using emacs seems to be moving to a line number (it takes a few more key strokes) and copy and deleting lines, it just takes a little too much work. Here is the link to my dotemacs file which is equivalent to .vimrc, though I suspect some of the lines in there are not necessary and can be trimmed down.

Inupypi 0.3.3 released!

We have just released Inupypi 0.3.3. Changes include:

Backend:

A lot of re-write has been done to make the code clean and re-organizations to make using and contributing to it easier.

Frontend:

Added bread crumbs support to the web pages to make navigations easier. On pypi.python.org README.rst was made to look good on github.com and pypi. More changes are planned, just visit our github page to find out what we have planned.

Please test it out help by sending us suggestions or better yet report bugs.

Editra ... the good and the bad. Does the search end here ?

One of a great find that I found via my search and in the comments in my blog is the Editra editor. This editor has been around for sometime (2005 if the website's timeline is anything to go by). Editra is mainly a one man show namely a Mr. Cody Precord. Editra can be installed by using most Linux packages, Mac or even using the trusted: 'pip install'.

 Few of the things that I looked for in my evaulation of IDEs:

1. Easy / Right installer ?

2. Ease of configuration ?

3. Python tools ? Ease of use ?

I would say that Editra succeeds in 1 and 2 but falters at 3. What I like.. it's light and reponsive and do need a farm of servers' resources to run. The editor is easy to configure and most of the configuration item / controls are in the places where you would expect them to be. The layout of the window are intuitive and where you expect them to be and it's evident that this IDE really lives up to the hype "Created for programmers by a programmer". Heck, some so called "enterprise" grade editors controls and configurations are just funky and would take you half a day just to figure out where they are, so this in itself is an achievement worth mentioning. Well now that all the praises and niceties are out of the way, now let's get down to the grease and dirt to the unfortunate part of why Editra still could not wedge out PyCharm or Sublime Text 2 as my main work horse editor(s).

One of the thing that an IDE I feel should help me out with is the Source Control component of the code that I am working on. The source control section for Editra is a bit dodgy and takes a few run overs to figure out. So far the editor which handles this the way I like the most is Sublime Text 2. Something however must really be done on how Editra handles VCS files. Sometimes it would work and sometimes it would not. Although I checked out the whole source tree from the same repository, some files were versioned and some were not ? Up until today I am still trying to figure out how to view changes of changed file on the VCS. I even tried the latest version from the Editra Plugins repository but no cigar. It would just sit there and not do my bidding, worse it did not even spit out any errors which I could get a handle on in hopes of fixing it. When I went to the editra channel on irc there was no one there except ChanServ and me, so no help there too. According to the main editra site a Mr. Kevin D. Smith was responsible for the projects plugin which the VCS is part of, so probably I should try to contact him ?

I tried just about everything including the 'make patch' menu item but nothing happened too and guys showing this kind of logging for the app:

[12:24:07][app][info] Going to sleep
[12:24:09][app][info] I'm Awake!!
[12:24:12][app][info] Going to sleep
[12:24:13][app][info] I'm Awake!!

I can dig that this is supposed to be a programmer's ide but this is not really what I would call informative or helpful!

Snippets

As far as I can tell, Editra does not currently have snippet support or allows you to create/add your own snippet. This powerful feature can be found in PyCharm and Sublime Text 2 and is something I used daily.  This is a big downer as mastering snippets would really reduce the number of keystrokes you have to do daily as well as get your typing speed up to your thoughts (well almost).

In conclusion, I can only say that I just feel the most frustrated about this editor. Not that it's lousy just that it has so much potential but all of it lies unrealized.

Growing our bootstrap script

Our company currently is using a custom bootstrap script to install our application which is based on virtualenv. Our 'bootstrapper' does a few things:

1. Sets up virtualenv
2. Runs configuration scripts
3. Other stuff

While our script works and has served us well, when cleaning it up and trying to expand it's functionality it began to show it's cruftiness, the kind of whiff you get that maybe the script itself needs the help of some third party libraries. Two of the python libraries that I have seen that can help us are:

• virtualenv-tools to help us with cloning our virtualenvs
• unipath or py-path to clean up the parts of the code relying on os.path and gang (ugh really hate those)

It seemed simple enough initially, just add these libraries or third party applications and ensure that we install them on our live servers as well. So, there I was a confident idiot, accessing our production servers installing the required pieces, checking in the modified code ... going home for the day thinking that all was well. Well, all was not good and dandy. The next day my QA department looked at me with this crossed look because all of her test servers broke. Well of course they broke, they too used the same bootstrap script and they too needed to be installed with the new required pieces. "There must be a better way of doing this" I silently thought to myself, then I remembered testing out this application building system from the Zope foundation called "buildout". I wondered if it would be useful for me. I read through the docs and it seems it was just what I needed!

After numerous false starts (The acquaintance process took longer than I anticipated as grasping it's core concepts was not as easy as I thought). So now here is how I do our bootstrapping using buildout, I create a buildout.cfg with barebone contents:

[buildout]
parts = cot

[cot]
recipe = zc.recipe.egg
interpreter = python
eggs =
    virtualenv-tools
    virtualenv
    configobj

Then I run

python bootstrap.py -d

then to finally pull in my bootstrap's library requirements in the form of local eggs.

bin/bootstrap

In this way it's self contained and I need not touch any of the system's python's libraries. Nice! Finally I can run my bootstrapper with:

bin/python mysuperbootstrapper.py

Then after the bootstrapper runs it's course, I can activate my virtualenv and hand the reigns there. No need for me to manually go in and ensure that all of my bootstrap's system requirements of python libraries are met. Done!

There are few places where this workflow can improve, one that comes right off the bat is why not just make the whole thing a buildout process. Well, I am looking into that as there are more than a few places where our setup.py files has to be rethought and better-ed. I am looking at that and hoping to reshape our whole deployment plus bootstrapping process hopefully based on buildout. I am also thinking of reshaping our testing process around buildout to get rid of retarded stuff like installing nosetests on production servers.

I will post my findings on our progress in the migration process ... as for now I am complete.