On Tue, 12 Mar 2013 16:38:55 GMT, Robert wrote:

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:

  1. Query github for each folder? Or maybe there is a function to return the directory structure?
  2. Download the archived project .zip file, scan it, and delete it again?
  3. 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.

Yeah, it depends if it has efficient means to list all files. I haven't seen one, but I haven't searched for it either.

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.

I thought about warning just for leaves of the package tree, so e.g. those two would conflict:

somelib.subpack1
somelib.subpack2
somelib.subpack2
somelib.subpack3

But this one wouldn't

somelib.subpack1.subsubpack

Another probably better idea would be to only include packages in the list that actually contain modules. That would be a more conservative approach, where it can still be guaranteed that there are no conflicts, but still it should be sufficiently flexible.

On a different matter, should we also warn about conflicts with -J files?

I tend to say no, because they have a defined override behavior and this is very useful to customize Diet templates of dependencies. A more explicit way would be desirable, but I don't know how that should work without uglifying the API.

Regards, Sönke