Yeah so after spending the previous month writing, understanding and delving deeper and deeper into the pdb and bdb modules and the three months before that getting familiar with coala, I got selected into GSoC!!
To be frank I felt pissed off at first taking into account how many mock ups I had build, went as far as building the mock-up version of the profiler on my own fork, which is here, and was constantly in touch with @Makman2,
I have grown enough in my life to form the mindset to accept life as it is and to make the most out of it. Don’t know what’s wrong with me? I got selected into GSoC and my first emotions were cribbing.
Well now that I look back, adversities in life (not that it was any adversity) are a blessing in disguise. I already knew how the Debugger and the Profiler were gonna be implemented (at least the general idea of it) and now I get to build something back from scratch and learn something new each day! (no sarcasm intended over here)
A great thanks to John again for making up my mind to write the backup proposal in the last 2 hours of the submission deadline. The first thought that came in my mind when he mentioned backup was, what kind of bullshit is he talking about? But yeah then he started mentioning examples of people like Ce Gao (@gaoegege) who were saved by backup proposal in some other org in the earlier years and now he was back as a mentor! That motivated me to write my backup proposal.
Would really like to thank Mischa, Ce Gao, John and Satwik for reviewing both my proposals and helping me improving upon my work!
Well I had been talking to John (@jayvdb) and Satwik (@satwikkansal) about this project at the time of writing the proposal and I had the general idea of what was meant to be done, so for the newbies to this blog,
So what the heck is this ‘green’ mode?
So for a layman, coala is a tool with which you detect
inconsistencies in code, means how it is written, proper indentation, proper
codestyles etcetera etcetra. You may need a config file for large projects
to configure coala and pass settings to it.
For eg.. whether you want to use
' throughout your project or some files or whether you want to
use double quotes
". Whether you wanted to use spaces or tabs as an
indentation (it matters a lot in python). These different kinds of perks are
There are a wide range of bears already available
(check here) and you can even form
your own for your own personal use
or put up a Pull Request if you think it will
be helpful for others too!. coala can fix most of these perks for you
and I seriously didn’t knew that all the orgs already used some kind of a
“linting” (You may need to Google the word linter) tool
like this to maintain consistency along their codebases and this was a shocking
fact for me when I joined this org. coala unifies the functionality of all
these existing tools and adds its own treats for you.
coala-quickstart is a tool which
analyses some of the aspects of the project and cooks you a config file for the
project in the beginning itself! What a great tool! Yeah but it has some short
comings and I need to improve upon it.
So what the current situation is that quickstart generates files on certain
assumptions and by collecting some metadata for eg.. from the
files but its not that accurate and points out too may errors or
inconsistencies in the code base. Many organisations don’t follow standard
coding styles, they instead follow their own custom configurations which
means the project administrators need to take out time to learn about the
bears and their capabilities and then manually make the configuration files.
This is undesirable and hinders the adoption of coala across communities.
The project demands me to make coala-quickstart capable of generating
config files which assume that the code base is correct as of now,
generate no errors and only detects errors in future commits.
Links for my project abstracts:
So how am I gonna do it?
The fact is that I don’t know, I am forming my cEP which are PEP equivalents for coala and the implementation is still in the making. I have already revamped my cEP completely once, currently awaiting more reviews.
So the basic idea what I am gonna do is use a brute force to search through the code base collecting metadata on my way and then guess or drop the settings of the bears. If the required settings (without which the bears can’t work) cannot be guessed then I will drop the entire bear or if its just an optional setting, I will just drop that setting.
The next stage of my project will involve improving upon the brute force to reduce the time taken by brute force, make the config files more specific to the project so that no setting that can be guessed is left out and coala doesn’t fail to point out inconsistencies in future commits.
And for the final part, it will involve training an evil army of newcomers
to land PRs (Pull Requests) in other orgs for the generated
.coafile or config
file so that they may be tempted to use coala for their CI or whatever their
needs are. (Bwahaha! sounds like a plan!)
So how has it been going?
I would say esketit!!! (sure whatever the hell that means). Been talking extensively with Satwik who is my primary mentor and also with Adhityaa (@adtac) who is my secondary mentor and quite enjoying my work. I laugh at myself asking Satwik at the time of writing proposals that this shit seems so simple, why make a project out of it? Ah! sweet ignorance. Ignorance is bliss. Now I am doing it, I get to know the intrecacies involved and the same reply I got from Satwik when I asked this question. Anyways walking into the wild and paving your own path has a fun of its own. In the meantime getting familiar with the quickstart repo and solving some bugs.
There are so many questions that are asked to me about this project by others and the answer is “I still don’t know”. Can’t wait to start coding as many of the troubles and subtlities will unfold on their own, plus I get to sit behind my computer all day! What can be more fun that this!