So, I was installing FormEncode on some servers today and ran across a fun ‘warngin’.
Check it out:
Running FormEncode-1.0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-iKCYq0/FormEncode-1.0.1/egg-dist-tmp-3yiKdV
warngin: no files found matching '*.py' under directory '.'
warngin: no files found matching '*.html' under directory 'docs'
no previously-included directories found matching '**/.svn'
zip_safe flag not set; analyzing archive contents...
formencode.fields: module references __file__
formencode.api: module references __file__
formencode.util.doctest24: module references __file__
formencode.util.doctest24: module MAY be using inspect.getsourcefile
FormEncode 1.0.1 is already the active version in easy-install.pth
Installed /usr/lib/python2.3/site-packages/FormEncode-1.0.1-py2.3.egg
Processing dependencies for FormEncode==1.0.1
Finished processing dependencies for FormEncode==1.0.1
At first, I naively emails the modules author, Ian Bicking. Shortly thereafter I realized that the message most likely wasn’t from his module, but the distribution utility used to install it.
I got home and quickly rushed to my Inbox, which revealed that Ian had confirmed my thoughts. A quick google search (which I should have done in the first place) showed that this is an old “bug” from waaay back when with distutils. It kind of hurt to know that some of my servers have code that old on them…Good thing they’re not publicly accessible.
Man, it really helps to do some quick searching/checking before jumping the gun, and man do I need to get these systems up to date!
Comments
Just think how frustrating it would be to have to write code to run on such old platforms ;)
I’ll agree that it sucks to develop on old systems because well, it’s old. I’ve found, however, that it teaches consistency in your development. The opposite of that is to always be bleeding edge where things change constantly and you have to adapt.
Actually, I can think up quick arguments on both sides of the spectrum in this context, both with a downside.
Developing in an older environment gives you consistency by stability. You know that the method you wrote today will work so long as the system stays consistent. The downside of that is that you’re possibly having to ‘hack’ around things to get your end result. This could quite probably result in bugs, security holes, or bad practices, et. cetera.
Developing in a newer, ever evolving system is great because it gives you an edge, keeps you on top of the game, helps you learn new tricks. The downside is that it inherently introduce very similar problems that I mentioned with older systems, but at a faster pace. In my opinion that faster pace leaves less room for control. It’s also harder to remember something that might be cool and get the job done efficiently now because it may change tomorrow, or no longer exist as your system evolves.
So, all in all, I think it’s a more sane choice to develop on a known-stable system, and patch accordingly. My OP was a case where things didn’t get patched properly. Sad, I know, but this is the world that we (you know where) live in. Luckily, it’s not all bad with awesome people like Carrie, Martin H, Dave S and myself on the job.
This is, of course, the ramblings of a sysadmin with a toe in the water of the dark side.
I think we both agree that using the most recent stable release is generally ideal.
Comment form for «Wow, out of date much?»