The root of the problem is the root: How to get a root at all times in a codebase (or no root at all) about commoncode HOT 5 OPEN

@JonoYang @tdruez @Pratikrocks @chinyeungli FYI

from commoncode.

Generally when we are having a single root the rid of 0 is assigned to the first resource and we are treating it as a root

from commoncode.

@Pratikrocks I think we likely do not need a root at all

from commoncode.

@pombredanne I believe we are leveraging to some extent upon the root when we are walking the codebase then basically it is the root we visit first .

from commoncode.

As stated above, we need to align commoncode's Codebase/VirtualCodebase class and Resource class with scancode.io's Project and CodebaseResource model. I would like this done such that code written to work with commoncode's Codebase and Resource classes can work on scancode.io's Project and CodebaseResource model. This is important in the case of fingerprinting Package Resources using the matchcode-toolkit fingerprinting functions (https://github.com/nexB/purldb/blob/main/matchcode-toolkit/src/matchcode_toolkit/fingerprinting.py#L69) because the fingerprints depend on the order of Resources when we walk a codebase. We want the codebase walk to be the same across both classes.

One of the issues is that we need to reconcile is that commoncode creates a root resource for a Codebase where scancode.io does not create one for a Project. The root is used to determine where the root of the codebase is and helps us perform depth-first traversal into the Codebase.

An idea would be to treat the Codebase/VirtualCodebase class as the root resource, since the Codebase represents the entirety of the codebase being scanned. This would involve adding the Resource class fields to the Codebase/VirtualCodebase class, so we can return the Codebase like a Resource when we are walking a Codebase or Resource. Resources that are in the root of the project would have the Codebase as the parent Resource.

Some issues:

• In scancode, the Resource model is created at runtime, where fields from active plugins are added to either the Codebase or Resource model. How would we add these fields to the Codebase? Would we have to do something similar to what we do with Codebase.attributes?, maybe a specific Resource object created as an attribute on Codebase?

from commoncode.