Let me point out though why you might want to consider using setuptools instead of doing it wrong.
Part of the PEP 8 and PEP 328 is that absolute imports are used as often as possible. The idea is that you specify exactly which module needs to be imported to make the code work. Even if the code is relocated, it still works. It also means that the system can arrange the files any way it wants, so long the Python interpreter sees the same structure for the modules. This lets distro developers and operating system designers put Python modules wherever they feel necessary, as well as letting tools like virtualenv override the OS defaults on a per user or per application basis.
However, if you use an 'alternative' directory structure in your project, you might find yourself running into trouble. Say you have a module you're building called 'foo'. In your source directory, you have some directory /src/foo/some_code.py . There's also some script /run_foo.py at the top level of the source tree. If there is a line in run_foo.py that calls 'from foo import some_code', Python will raise an exception that the module foo cannot be found.
One common, although very wrong and messy solution is to catch said ImportError. In the corresponding catch block, there is alot of code to check to see where the code is being run. Then it digs into the internals of the module import system in Python so that it pretends it can really see the module foo and all its submodules. This is a rather unfortunate way of writing code, because it really limits what you can do in the source tree. For every script that you have, you may have to copy and paste this code. Furthermore, if you change the layout in the source tree, you may break all your scripts and have to change them manually. Finally, you have to question the sanity of putting file system specific code in a program. There are clear places where such code makes sense, but tinkering with the filesystem and path environment is not one of them.
Luckily, setuptools can do all this work for you. It can translate any on disk file system layout, such as /src/foo/some_code.py to foo.some_code for you. It can also direct installation to work properly. It can even modify your Python path environment so you can work directly out of your source tree. Any changes you make will show up automatically. Finally, we can isolate all the code into one place. The entire mapping is just a simple dictionary in one file, which is analogous to a configure.ac file.
I may post something later about where setuptools fails, and how we might be able to work around it.
I want a Fedora Everything on floppy. My work machine, despite having entirely new hardware inside right down to a complete lack of PATA controllers, has a floppy drive. I want to relive the experience of installing Debian via floppy, but this time in Fedora. For old times sake. I want a pony.
I went to update my system, and noticed something interesting. Yum, while rebuilding the rpms out of delta rpms, gives a bandwidth meter on how fast the operation is going, and as it turns out, yum is slower than just pulling random packages from the internet. In some ways, running Presto actually slows down updates when a fast connection to the mirror is available. It stands to reason that in any network running a local mirror, Presto is probably not needed either.
So do i keep Presto enabled? For the time being, i will. The extra CPU time costs my employer money, which i'd rather do than use up someone else's bandwidth. While we're probably talking fractions of pennies here, with the number of Fedora users, such things do add up.
Pre-sale closing July 20th, HoaB, first-aid needs help
For those of you who still have not got their ticket for HAR2009: the
pre-sale discount of EUR 20,- only applies for less than 96 hours. With
the discount, a ticket sells for EUR 185,- (or EUR 180,- if you enter
the coupon code `FNLPPRCH'). After July 20th, without the discount, the
price will be EUR 205,-. In addition, if you plan to use direct
transfer (IBAN/BIC), this is really the last chance to buy a ticket in
advance. After July 20th, the tickets will sell for the door-price, and
only credit-card and iDeal transactions will be possible.
So, if you haven't already, head over to the ticket shop now and
get your tickets for Hacking at Random. Not only does it give peace of
mind, knowing that you can get in regardless of whether the event is
sold out or not, you're also making sure that this will be the last
time I have to write a few paragraphs to implore you to get your
Hackers on a Bike
Some of the more sturdy hackers are planning to cycle over to Hacking
at Random: a smart, healthy and environmentally friendly way of
traveling to the camping grounds. Although the title may lead you to
believe this is some crazy scheme involving one of those lethal
beer-bicycles, there will not be multiple hackers on a single bike. The
participants will each commandeer their own bicycle. To find out all
the details, check out the wiki page.
The original plan included departure from Wageningen, NL (which is
actually not too far away from the event) but by now other routes are
being planned. A group will depart from Amsterdam, and there are even
people who start in Belgium or Germany. I tip my hat to your stamina!
Some of the Hackers on a Bike might break free of the regular
proceedings for a day trip cycling around the Veluwe, which (you might
have heard) is one of the better offerings nature has in the
(Actually, Bert is taking the train to Wageningen, he's not actually biking all the way from Belgium ;) ).
Team:First-Aid looking for qualified volunteers
Do you have a first-aid diploma (Dutch EHBO or BHV certificate, or
something equivalent)? You speak English very goodly? Are not afraid of
blood? Capable of staying sober for a sustained period of time?
Prepared to miss some lectures to man the post?? Then you are what the
first-aid team is looking for! The nights are pretty much covered,
however during the day this team can certainly use your help.
The first-aid team is first in line when someone hurts himself. You do
not need to be a MD, however some basic training in first-aid (and
something that says you successfully completed the training) is
required. Serious medical problems will be for the official emergency
services, the team only has supplies and expertise for basic medical
care in case someone cuts her- or himself, burns her- or himself (not
unlikely with all the soldering going on) or sprains an ankle.
If you are interested, please check out this teams wiki page.
Well, i still would like to have access to a couple of programs that i just can't seem to get to work right on wine and/or other methods. Being the secular stallmanist i am, i don't mind using open source software on windows now and then, and there are a few programs i like to use. Hearing about the updated VirtualBox release that now does 3D acceleration pretty well, i decided to give it a try. Yes it works :D. Unfortunately it does not work with SELinux in enforcing mode, but i don't mind switching to Permissive for the few hours i need to do something with it.
On a completely unrelated note, the FUDCon bracelet i've been wearing for about a year now finally broke at work yesterday. I have another one, but i haven't decided if i want to start wearing that one now. Does anyone else wear them still, or even abuse them to hold doors open to overheating server rooms?
The FAD at Random 2009 will be held near Vierhouten, August 15th at Hacking at Random. The topic of the FAD will be Media and Media arts using Open Source in general and Fedora in particular. The format will be pretty free form. There will be a few tents for hacking in and a tent with a projector to do presentations. We will hold a barcamp where people can do presentations or just show off demos. Some people from the village will also be VJing sporadically during the event, although the entire thing is ad-hoc.
We will also be forming a village between these four groups for the duration of HAR, so be there or be something not round.
I was given the choice, to run memtest tonight and let it run all the way through or to try with random sticks of RAM tomorrow. I opted for the latter because it means not keeping the machine on all night long. But is it really more green? Those sticks of RAM have a certain environmental load too. Is it better to run energy using tests on the currently existing hardware or check every point of failure with a backup known working set? Which is more green? Should we even worry about such decisions at all?
Flickr Link Here
Literally it means the seat is not a garbage dump, but Berlin is quite a liberal city, so i'm going to use quite a liberal translation.
1) "Halp! I can't read my email!" - I'm clearly not responsible because that's handled by a central agency.
2) "The printer is broken." - I'm not a janitor, clean up your own mess.
I'm already loving this job.