Group related files together (such as the files of a package, build scripts, etc)

[pombredanne]

Description

It is common for many packages to be vendored as-is and/or bundled in a codebase. For instance an npm tar ball or codebase may contain a node_modules directory with a tree of dependent npms as declared in a nearby package.json and/or lockfile. The same applies to several other package types: vendoring of Go or Gems or Composer for instance.

In this cases, it would be best if we could distinguish and report separately:

1. which files are part of the main package
2. which files are part of the bundled packages

When defining break/summarization points in a codebase or package scan, that data would be quite useful.

This is orthogonal to and quite different from reporting dependencies as these may or may not be bundled at all.

[pombredanne]

Following the comments I made here #1237 (comment), we have something that is more than just for packages and would be essential for #377 : we need to group files as being related:

• this is the case for the files provided by a package under its root directory,
• this can be also the case for files that exist in multiple unrelated trees (such as files located in src/ and include/ but are from the same package; in some C/C++ layout they can be scattered in a codebase)
• in some other cases (such as nested node_modules directories or nested Maven POM projects), not all the descendants of a package directory may be part of a package file set
• build scripts are also defining such file sets such as in Add support for build tool manifest files as proxies for packages  #1553

So I am renaming this ticket to deal instead with the automated determination of these file groups.

[pombredanne]

This has been implemented by @JonoYang with --consolidate

[pombredanne]

This is now implemented in the new package handler design: in the "assembly" step, the files of a package are tagged as related to a package instance. Eventually multiple related manifests and lock files contribute to top-level package instances.