Week 6 was the start of Phase 2 of our Google Summer of Code. As I mentioned in my previous blogs, we are now working to build a new Worker in Augur for calculating the libyear which is a measure of dependency freshness. These weeks were a lot about researching and deciding on the architecture for the worker.
But what is Libyear and dependency freshness?
This is a good question, dependency freshness is a fancy way of telling how updated are your dependencies. Dependencies have a version, all developers keep updating them which fixes bugs, makes it more stable and, improves a lot of other things. So it is always a good idea to keep them up to date or at least keeping them close to the latest version. Libyear is just a unit to measure dependency freshness. It is simple, it looks at the latest version of a dependency and its release date, then it looks at the version that is being used by us and its release date. It is calculated as the days between the latest release and our current version release date and divides it by 365 to give us a number that would represent a Libyear. It is considered healthy to keep the libyear less than 1. We have some tools for libyear calculation but they come with their own set of limitations.
What are those limitations?
Well, to explain those limitations let’s know a little about the tools. So right now we have 8 different tools listed on the libyear website, all these tools support different languages and their package files. For example, the tool for pypi would calculate libyear for python repositories. These tools look for package files and parse them to know about dependencies and their versions. So the first limitation is the tool’s support for the files. The pypi tool would only look at requirement.txt files, but in more mature python project like augur, they use setup.py to store the list of dependencies and their versions.
Another limitation is that these tools are written in different languages which support different packages. Implementing them directly would be a problem as it would require more dependencies in augur, which in turn may make augur installation even more complicated. Right now to implement the scorecard we have made a necessary condition to install GO on our local machines while installing augur. Just going on adding dependencies would be a bad idea.
Well, then what is the solution?
The solution has two alternatives either to start making a new tool from scratch to calculate Libyear, or for the time being use additional dependencies for the tools. We are yet to decide on this. In the meanwhile, I also looked at how libraries.io is solving the problem, and how I got to know about it is a very fun story. It started with looking at their main repository and I couldn’t find anything for days, all the functions were taking dependencies and versions as their parameters but I didn’t found anywhere how they got the list of dependencies. So I decided to contact their top contributors. The first contributor had his twitter handle on his GitHub page and I sent out a message to him on twitter. The second one had his email-id, so I sent across an email with my queries. The third one had nothing listed, no email no twitter, just had that he worked for fedora. So I searched his name on LinkedIn with fedora and I finally found him. Guess what, he was the one who replied. Crazy right?
How is Library.io getting the dependencies?
Library.io uses a ruby library called bibliothecary which parses all kinds of package files to get the dependencies. This library is built by libraries.io and seems to be using regular expressions to look for dependencies. To use this library we would have to introduce ruby dependencies for Augur or the option would be to write something of our own like library.io.
I am trying to implement our parser for augur in python, if it doesn’t work, we may have to use bibliothecary directly as ‘Working code is better than no code’. Let's see how it turns out!