Document how to work with several projects in the same repository
hunger opened this issue · comments
Thank you for the reuse tool, it is really helpful!
I work on a mono repository that contains several projects that are released together but independently. I tried to set this up by using reuse independently on all the projects ()so that these can be verified/get a BoM independently from each other), each with a separate LICENSES folder and that works fine. reuse reports all of these subprojects as compliant now. Yeah!
I also have some files in a "top level" project, e.g. the build files that build the entire thing, etc.
That works mostly, but the top level project, apparently ignores all the information in the subprojects .reuse/dep5 files. That makes the toplevel project complain about files not having license information.
Is a setup like mine supported? Are there any best practices to follow for such a setup?
Ideally I could end up with a setup where I can independently check the subprojects for compliance (and get their bill of materials) as well as the toplevel project. The leater should ideally include all the sub projects BoM as well...
This is probably not a bug, but maybe a feature request or maybe just a request for documentation.
From what you write, the basic problem is that .reuse/dep5 is only respected on the root of the project, not in subfolders. That is intended to limit the places where one (and tools) have to look for REUSE information.
What could work is adding the child projects as submodules. There is the flag --include-submodules but I am not sure whether it treats the submodule as an isolated project then with its own dep5 file (but it should).
In the future, we hope to be able to offer a more flexible option than dep5, currently under the working title REUSE.yaml. See spdx/spdx-spec#502 for the current state.
Ideally (for my use case), any folder containing a .reuse/dap5 file would be ignored by the parent project. Instead reuse would be run in such a folder and the results of that run would be aggregated into the main project somehow.
Not so ideal but manageable would be a way to simply avoid looking at any folder containing .reuse/dap5 files. That way I could have a top level project that does not raise warnings about files covered in a sub-project.
Unfortunately the crates heavily inter-depend on each other during development, so I would like to avoid git submodules!
This is what I want to use reuse on:
I have a rust project consisting of several "crates" (think: libraries). I want each of these crates to be independently verifiable by reuse as each crates is uploaded to the central repository of crates independent of each other. Each crate only contains its own source code in the crate repository. So I set up reuse per-crate to enable this.
I also have some files (overall build system, some documentation, CI setup, etc.) that is not part of any of these sub-crates.
So I would like to have the top-level directory covered by reuse as well, ideally alerting me of areas I missed to define a sub-project for.
I would also want to quickly scan the entire project from CI when I do changes to make sure things are properly licensed. For that it would be wonderful if I could also run reuse from the top level. For that some form of aggregation of sub-projects would be cool.
I hope this gives a better picture of where I am coming from than the original issue. Sorry, it seemed totally obvious and complete when I wrote it:-)
I understand your use case. However, I am afraid that we won't tinker with allowing more than the current location of the dep5 file at the root of the project as valid sources of REUSE information.
We are looking into soft-deprecating dep5 and replacing it with REUSE.yaml which would also solve your use case. Currently, this is blocked by SPDX, so please feel free to +1 the issue I linked in my previous comment.
Until then, I am afraid we cannot provide a native solution for this case other than a) submodules or b) getting rid of dep5 in the crates, sorry!