Google Summer of Code 2018 Report
Task:
To develop a package manager prototype for ROOT. ROOT is a data processing framework created at CERN and used by scientific community, particularly in High Energy Physics (HEP) field. The defined task was to initiate a modularization process for ROOT and to provide a simplified installation routine for ROOT using a package manager. In a collaborative effort with GSOC mentor Oksana Shadura and under supervision of other GSOC mentors Brian Bockelman and Vassil Vassilev, we created a package manager for ROOT - ‘root-get’.
Work done :
Community Bonding period
I learned about existing package managers focusing on Swift package manager and C++ package managers (e.g. Hunter, Buckaroo.). I got an insight about the overall structure and usage of package managers in software development. Later I added continuous integration for ROOT ‘base’ (ROOT minimal image with ‘core’ functionality: core, interpreter and I/O functionality)
The work will be ported to the ROOT git repository as soon as changes needed to be able to build separately core part of ROOT functionality (“ROOT base”) will land in root.git master.
First Coding period
Initial development started with discussions about structure of root-get with respect to ROOT “base” (ROOT minimal image with ‘core’ functionality: core, interpreter and I/O functionality) organization in packages and modules. The use of manifest files to get only the relevant and necessary attributes for a package or module plays crucial role in root-get flow.
The package/module database for root-get was initially hardcoded. My task involved creating a routine to generate the ROOT package and modules manifest files at ROOT runtime for root-get purposes. This should allow to move to active development of root-get and it’s basic functionalities.
This involved working with CMake and the ‘ROOT_STANDARD_LIBRARY_PACKAGE()’ CMake macro on a side of ROOT [ROOT “base” image] repository. After spending some time on learning the CMake and it’s syntax, I was able to create the dynamic manifest generation routine which involved both work with python and CMake.
During first coding period, we developed a basic package manager functionality and test it for ROOT.
Second Coding period
The tasks included teaching root-get to show the list of available packages and also the installed modules. This also involved work with algorithms of iterative walk in directories and studying regexes and it’s usage in python.
The task to provide a routine for complete ROOT package installation, queries about available and installed modules using root-get command was implemented.
The task to get the correct entity name made me learn about the fuzzy search for texts, overview of Apache Lucene.
I did further work on studying about DAG and its usage in dependency resolution.
Third Coding period
Major part in this period involved handling possibility of the external package/module installation routine. To plug modules into ROOT and treat them the similar way as ROOT packages required some iterations and modifications in the routine.
Other part in this coding period involved creating a topologically sorted dependency (DAG) graph, to be able to resolve dependencies using it and as an addition to be able to visualize dependencies with a graph library (I was using NetworkX module for this task). Also, I am working on documentation part for root-get (adding README.md and writing code documentation).
Things left to do :
Integration of root-get and ROOT runtime. Due to the complexity of this task it was moved out of the scope for GSoC 2018.
Next steps :
Currently the root-get project is in prototyping mode and the work will be continued on improvements and root-get will be moved from oshadura/root-get.git to root-project umbrella for community use and further developments by ROOT developers.
The root-get project repository with all the GSoC 2018 work and current developments : link
following are the merged PRs - (dates differ from actual coding period timeline as the changes were merged together into above repo later than their actual implementation) First coding period work related - 1, 2, 3
Second coding period work related - 4, 5.1, 5.2, 6.1, 6.2, 7, 8, 9, 10, 11