python setuptools: workaround for ignore specific files

It seems like this is a pretty common issue.  People want to ignore a certain file/module in their distribution.  Typically a file resembling: “settings_local.py”.

Well, today I searched around attempting to find an elegant solution and I just couldn’t seem to find one.  So, out comes the monkey patching…

If anyone has this same problem, please comment on how you did it.  Here is how I did:

from distutils.command.build_py import build_py

#
# modify build process to exclude specific files from the build
#
find_package_modules_old = build_py.find_package_modules

def find_package_modules(self, package, package_dir):
    excludes = [ 
        ('pkg','module','pkg/module.py'),
    ] 

    modules = find_package_modules_old(self, package, package_dir)
    for pkg, module, fname in excludes:
        if (pkg, module, fname) in modules:
            modules.remove((pkg,module,fname))
            print "excluding pkg = %s, module = %s, fname = %s" % \ 
                (pkg,module,fname)
    return modules

build_py.find_package_modules = find_package_modules

why do people program perl these days?

With so many other awesome alternatives, I don’t understand why people use perl.

Just the other day, I was programming in perl (at the day job… as I have written a considerable amount in perl already and haven’t gotten the infrastructure in python yet to switch over).  I noticed how poorly the support is for Windows.  Alright everyone, guess what perl returns from this on Windows:

C:\Documents and Settings\username\> perl
use Cwd;
print “cwd: “.getcwd().”\n”;

Well, if you guessed “C:\Documents and Settings\username\“, you are wrong.  In perl, of course, its actually “C:/Documents and Settings/username/“.  I realize it “happens” to work (as in, some windows versions support it… not perl), but I’m not ok with it “happening” to work.  I need it to work.  I don’t want my code breaking on something so simple as a path separator.  And it really isn’t that hard to support both / and \.  Sure enough though, I can’t trust perl to “do the right thing”.  I end up hacking around everything perl has in its standard library.

Another doozy is when you start using File::Find and find out, it doesn’t work on Windows with no_chdir.  Why? Not sure… And I don’t much care.

I guess, what I’m curious about is, how many people still see a good reason to use perl.  One that doesn’t include “we already have an entire infrastructure coded in perl”.  I understand no one really likes “rewriting” code and that it has a batch of its own problems such as reintroducing regressions and is “needlessly expensive”.  However, I would think those projects go away over time.  New projects should use newer technologies and get the old and new technologies to work together.  And eventually, maybe, phase out the old stuff.  Maybe its not something that someone converts overnight, but at least move in the right direction.

My biggest problem with perl is that its standard library is hard to trust to “do the right thing”.  A language in which this stands true is very hard to program efficiently and effectively in.

Django makes web development… fun?

Fun may be going _too_ far, but it is a heck of a lot cleaner than anything I ever hacked up before.  To be honest, I really stayed away from web development before I really gave Django a try.  Now, I’m almost ready to start writing my own website/blog/everything (I know, cliche) in Django.

I’ve really gotta hand it to Chipx86 and Djblets though.  My first Django project immediately ran into issues with deployment.  Issues that Djblets immediately solved with the SITE_ROOT stuff.  I have to say, my inexperience with Django most certainly would have led me to hack in something not nearly as clean as what Djblets has in place.

One thing does bother me about the SITE_ROOT stuff.  It’s actually more of a Django problem.  It seems that after adding ‘djblets.util.context_processors.siteRoot’ to TEMPLATE_CONTEXT_PROCESSERS in settings.py, it doesn’t do anything.  In fact it doesn’t, until you use RequestContext() from django.template.context like:

render_to_response(template, RequestContext(request,{…}))

The TEMPLATE_CONTEXT_PROCESSERS are not used until you use RequestContext() which seems so very wrong.  Can someone explain this to me?

Anyways, I really enjoy programming django for the web (still not a huge fan of any web programming, but I’m warming to it…).  If you have working knowledge of python and web programming, I highly suggest Django.

why learn emacs?

I’d say I’m a pretty advanced vim junky.  I use custom scripts and have a decently large vimrc file.  However, I’ve never had any impetus to learn emacs.  I know there’s the never ending war of the editors.  However, I guess I don’t understand why someone would actively use emacs?  I guess I have heard its more “generalized” and can do anything from editting/writing your favorite programming language to cooking dinner (kidding…).  But why on earth do people use emacs?  Vim has so many convenient hot keys that don’t require a meta key modifier.  Why use two fingers when you can just use one!?

Any avid emacs users out there that can enlighten me as to why I should bother to learn emacs?  I feel like I should, but I just can’t find the reason and I like vim so much.

finally blogging again: gravatar.com

Wow.  I finally took the time to make an avatar (I know it blows…) and uploaded it to gravatar.com.  Man, its so slick!  A bunch of sites just picked it up and it worked!

Too bad some other sites don’t just pick it up, but github.com, bitbucket.org, and wordpress.com all work.  I was slightly surprised that twitter.com and identi.ca didn’t work.  Not sure what the deal there is.  Anyone know what the deal is?  Why haven’t they hopped on the gravatar train?  Seems like most everyone else has.  And I’m pretty sure I just found this out and its been around for a while…

Think they’ll ever support it?

kicking the ESC habit in vim

So I was recently enlightened to the fact that you don’t need to take your left hand off the keyboard to exit insert mode in vim.  Who knew!?

In insert mode, press ctrl+[ .  In fact, my guess is that it’s not a feature of a vim but an alternative to pressing the esc key which requires you to move your hand off the keyboard.  I feel like I knew this, but never really realized its application to exiting insert mode in vim.

Anyways, I’ve been pressing esc for several years now.  So much so, that if I use other editors (because vim is not around ), I will press esc in those editors too.  This typically happens on someone else’s Window’s box when they’ve asked for my help with something or other.  You can imagine that switching from esc to ^[ is going to be quite hard, but I’m determined to do it as I think it’ll be faster.

PS: this is a good read about efficiency of editing in general

fed up with Mecurial named branches, on to git

I finally gave in and switched my hosting of dotfiles from bitbucket to github.  I am absolutely sick of dinking around with named branches in mercurial.  Its just far too much work to get the job done.  I’m hoping git is slightly better.  It seems like it is.

I’m actually still a mercurial fan, but there seems to be a much larger community behind git.  I think a few years of maturing will do Mercurial good.  Maybe it’ll drop the named branches idea and side with git.  I’d like that .  I’m not sure I like how complicated it makes things.  I’m not sure how named branches is any different from having multiple heads constantly.  Oh well.  I will still fight for mercurial, but git is by far more mature, so it looks like I’m stuck with it.

[update] I was kind of running out the door when I wrote this, so maybe I should expound on why I switched from Mercurial to git.

First off, community support of git has really helped the community.  So much so, that github offers as many repositories as you like up to 100mb (which I hear can be upped if you need it).  Bitbucket, among other providers, only provide one repository.  While that may change, it was one of the main points in my switch.

Secondly, Mercurial is quite painful to maintain named branches, like I stated earlier.  Let me lay down the situation.  I have dotfiles on my home box which get modified for work use.  While they share many things, there are things that I need specifically for work and things which I can assume on my home box.  So in this way, I need to maintain two different branches of my dot files.  When I make a change to one, I’d like to port that change to the other.  I was using the transplant extention heavily with mercurial.  In git, its called cherrypicking.  The difference between cherrypicking a change with git and a change with mercurial comes down to one minor difference.  With mercurial, its very strict about its merging.  In mercurial after you transplant, you need to merge the named branches together or you have a multiheaded repository that cannot be pushed to the server.  The merge actually doesn’t merge any files, it just merges the Mercurial tracking which gets really annoying. Git doesn’t require this.

Thirdly, I’m not thrilled with how mercurial requires multiple directories which forces people to copy the working directory multiple times to branch.  At first, I didn’t believe it to be a big deal, but when your working tree is >400mb or even 2gb, this is a huge hassle.  It takes extra unneeded disk space.  Git handles this gracefully with its branching and remote tracking branches.

As for some of the questions about: In what way is git more mature? More feature complete? Better performance? More tools and supported platforms for these tools?

Git does have more features and better performance, but Mercurial will eventually have these also.  My decision is not soley based on features and performance as both can be fixed over time.  The main part of my decision is based on Mercurial’s decision to track files (not content), named branches and required cloning as a means for temporary branches, and the annoying feature that requires merges not due to actual code/content, but due to its internal tracking tree.

Don’t quote me on that last comment as far as the internals go, but I’m fed up with having to do hg merge and not actually merge anything, but just to satisfy the Mercurial internals.  That is a design decision that may take a while to work through and probably won’t be fixed ever.

I find this all very sad because honestly, I prefer the Mercurial project in so many other ways.  I absolutely love how easy it is to make plugins.  The plugin system is amazing.  The actual code is very well organized and really proves how python, as a scripting language, can still have performance.  It’s very extensible and things are much cleaner (IMO) in the backend than git.  Git seems more like a conglomerate of bunches of code which makes it feel less organized.

Even platform support is better for Mercurial, although I know there are some git fanatics out there getting it working on Windows (which rocks).

All in all, I love Mercurial on most levels, but I’m sick of fighting with it to get my job done.  I want branches like git has.  I want flexibility like git.  I just wish I didn’t have to use git, to get it.