Saturday, January 12, 2013

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.