Definitely, especially considering that we need to scan packages for all contained D packages anyway, it will be good to have that in place.
Perfect :-) It is time for me to become acquainted with the registry code base!
The question is how to best implement that performance wise:
- Query github for each folder? Or maybe there is a function to return the directory structure?
- Download the archived project .zip file, scan it, and delete it again?
- Some other way? Could use libgit, but that would limit it to git...
Hmm, without very much thinking, using libgit seems to be the best way, writing some abstraction so that the back-end is exchangeable for other vcs should not be hard. Also I have a feeling that this would be the most efficient, but we'll see.
The representation in the database would then just be something like a
string[] DbPackage.packages;field that has all D packages in dot notation.
I think just a list of packages is not enough, we need to to store the name of every file to detect conflicts. Two packages installing in the same D-package can be perfectly fine, thus we need to go down to the module level for both conflict detection and mapping source files to packages.
On a different matter, should we also warn about conflicts with -J files?
Best regards,
Robert