in-memory db.....or should I say in-ram

Yes, yes its true, when I first saw Issue 10 I was like "pfft that is easy just set a default file name in the options parser."

Anyways long story short, I miss understood the whole in-memory thing, yea hindsight is 20/20, I have now implemented the proper fix which ended up being just as easy, thanks to sqlite3.

Though I won't lie I made it out to be a lot harder then it was and spent a few hours doing erroneous things. In the end though I learnt lots about the server side of pony-build, so win-win.

STOP RIGHT THERE!......subprocesses

So I spent a majority of my pony-build time during the month of February working on subprocess timeouts. Cause face it, we don't want those pesky little things running forever hogging up our precious system resources. Visit this link for some visuals on the following information breakdown.

• First we need to grab the time the subprocess tarted running.
• Then we use subprocess to run any commands that where passed.
• We poll the process, grab the current time, then test to see if the time that has elapsed since start is greater then the specified timeout.
• If it is greater then the timeout we go ahead and start the kill process, windows first, since my Windows machine is down I am unable to test this code (bad!). The unix code however has been tested and works.
• In unix we kill the process then wait to make sure its doen before we carry on because if we don't it sorta defeats the purpose.

The theory behind the ImportError is if it is not running on windows machine we will get and ImportError exception and we can bounce down to the Unix code. During my research, as we can all guess, windows is a bit fussy and more complicated when it comes to OS level stuff. Once I get my Windows box back up or I can wrangle a work PC in for the job I will update with the results.

Midway....

Well it has been about 3 months since my Professor at UVI approached me with the opportunity to partake in UCOSP. I spent a few days reading up on the projects and talking to some people who partook in Fall Semester 2009 before I finally made my decision, which since I am writing this, must of been the right one. I settled with pony-build, there was no one else working on it, it was in its infancy, and I wanted to do something different, python, and who can pass up a project led by a guy named C. Titus Brown-- What does the C stand for?.....the world may never know. Its been up and down for me, I have had some scheduling issues and some procrastination issues, Hey! I live in paradise you know, can't ignore the ocean calling all the time.

I think I started out with these grand thoughts in my head, "Oh Yea! I will race through this and turn out some huge fixes or implementations." But, alas, as the days, then weeks have passed I have set my sights a little lower, but not too low! I have slowly started tackling small issues one by one, which after getting these implemented and working smooth is a great feeling. In this short period of time though, I have learned lots. Coming into this I knew very little python, "Hello World!"-- I now have a pretty solid base understanding of the language. I am looking forward to getting in to some more advance techniques over the rest of the semester.

The idea of UCOSP, itself, is great-- Getting us involved in some real world projects is great. We get experience working on a distributed team and we improve our skill set. Oh, and that little extra line on our resumes does not hurt either.

Indentation is Serious Business

That is all.

We messed up dude.

So this week I started to mess around with virtualenv some more and getting it to fail if pip can not install a dependency. Some info in no particular order.....

1) VirtualenvContext is just another context for running build scripts, but in this case it gives us the advantages of virtualenv . We can run the build script in a "fresh" environment, which leads us to why we need to have the pip integration. Pip lets us install everything the application will need to build and run properly.

2) You can follow a thread I started on the pb list to discuss how we would want to go about catching any issues pip may run into during the install process. The main issues, spelling(which basically means the pkg will come back as not existing) and just the pip process failing all together. Since we run under virtualenv we have no worries about rights issues, so it would come down to some other error - which I think we can catch with an OSError, stop execution and print out whatever the error may be to the user.

3) So far I am just testing for the pkg not existing. You can see the code so far here. Right now I think it is a pretty poor way to figure it out. Basically I am parsing the output from _run_command and looking for 'not'. 'not' shows up in the error from pip saying it can not find the requested package at the 40th place.

I think I finally all so got the mkdir stuff and Git to a final state. (Though its under the close scrutiny of ctb as I write this, so who knows). I changed things here and there, the core functioning of the process did not change but rather just a little "prettying-up" of things.

Slowing to a Trot

Well the semester is in full swing now and the work load is mounting. I would be lying if I said I was paying the amount of attention I should be to pony-build. Finding the time between full time student and full time employee at a busy IT consulting firm (which is staffed by myself and one other person) to devote to pb is rather difficult. What little time I have found to work on pb related stuff has been used to work on the following.

1)Make it so, if the cache_dir(~/.pony-build) does not exist, create it and do some initial repo checkouts.

• The whole point of the cache_dir is to remove the need to continuously checkout data from a public repo. Once the first initial co is done we can just grab the deltas int he future, then use the local cache for our building needs and checkouts.
• So there has been a few iterations that you can look through at : mkdir Started out doing the creation inside the different "Clone" classes. We will now move to just calling on a function that will check for and do whatever needs to be doen to make sure cache_dir is there. This way inside the classes we can just check for the repo dirs and either update or create. This cut down on the code needed inside the classes significantly.

I am hoping to get SVN and HG working with this implementation over the next few days.

Galloping out of the Gate

With the ending of the Spring Code Sprint this past Sunday, the pony-build team can get down to some serious business. At the code sprint I worked on getting jcobian's implementation of virtualenv support ready to roll out to the main pb repo, which it is now after some refinements by ctb. I picked up Issue 6 all so.

Right now I am working on getting pb to create the cache directory, which it uses to store the repos it pulls off the internet locally, and the repo folders if they do not already exist. It is sort of working now, but i am having problems with git and it trying to do lots of clones for some reason. Luckily debugging in python is fairly easy, asserts and print statements hah, good times.I just need to clear up a couple things with ctb and I should have a push to a branch of my git repo by the end of the week.

More detailed info to follow at that point.