| 1 |
Hello everyone, |
| 2 |
|
| 3 |
== Brief summary of this project == |
| 4 |
|
| 5 |
The aim of this project is to create scripts that automate the process |
| 6 |
of overlay creation/maintenance for R packages from repositories such |
| 7 |
as CRAN and Bioconductor. |
| 8 |
|
| 9 |
Longer: |
| 10 |
For the ebuild creation of a single package one needs to extract the |
| 11 |
package, copy-paste data from its description file to the ebuild and |
| 12 |
look up dependencies, which is time-consuming. |
| 13 |
Although trivial for a few number of packages, this is practically |
| 14 |
impossible to do by hand for repositories like CRAN (> 3500 packages), |
| 15 |
especially 'cause it also requires tracking changes (new / updated / |
| 16 |
removed packages). |
| 17 |
The solution is to automate that process and this is what this project is about. |
| 18 |
|
| 19 |
== Progress of this week == |
| 20 |
|
| 21 |
My plan for this week was to start with the dependency resolution. |
| 22 |
First of all, I defined and implemented a clear structure of how to do |
| 23 |
that: |
| 24 |
|
| 25 |
The actual dependency resolver consists of a "to-resolve" queue, a |
| 26 |
"depres-failed" queue and "rule pools" which are basically objects |
| 27 |
with a "matches (<dependency string>)" function. It also has a |
| 28 |
run()-method that puts all parts together; threading is intended but |
| 29 |
requires some more work. Communication with the resolver does not |
| 30 |
happen directly, but via channels instead. EbuildJobs (an object that |
| 31 |
handles/represents ebuild creation for a single R package) use |
| 32 |
(private) EbuildJobChannels to enqueue dependency lookups. They then |
| 33 |
wait until the resolver has processed their request and use the result |
| 34 |
or report failure. |
| 35 |
|
| 36 |
The rule pools allow for easy adding of various (rule based) |
| 37 |
dependency lookup objects in future. I've already implemented one, the |
| 38 |
"simple" dependency rule pool which uses dictionary-like rules ("fftw |
| 39 |
means sci-libs/fftw" for example) read from text files; ignoring |
| 40 |
dependencies is also possible (like R which always required and |
| 41 |
therefore a dep in the eclass). |
| 42 |
|
| 43 |
Overall I've managed to create a working dependency resolver (with |
| 44 |
some Todos) this week and I'm on schedule. |
| 45 |
|
| 46 |
== Plans for the next week == |
| 47 |
|
| 48 |
* improve dependency resolution, add some functionality (e.g. listener |
| 49 |
modules that log unresolved dependencies to a separate file) and make |
| 50 |
it more thread-able |
| 51 |
* add Manifest / metadata creation |
| 52 |
|
| 53 |
-- |
| 54 |
Regards, |
| 55 |
André E. |
Archives