Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linter does not support dep5 of git submodules #163

Open
dmorn opened this issue Feb 6, 2020 · 7 comments
Open

linter does not support dep5 of git submodules #163

dmorn opened this issue Feb 6, 2020 · 7 comments
Labels
bug Something isn't working
Milestone

Comments

@dmorn
Copy link

dmorn commented Feb 6, 2020

Steps to reproduce

Create a new reuse project under git. Add a git submodule which is compliant with the reuse specification, but covers some files with debian's dep5 mechanism. If you run the linter on the parent directory (not the submodule), it will complain that the submodule is not reuse complaint.

Example

Let's create an empty git repo first, add the submodule and check its complaincy:

danielmorandini@jecoz ~ % git init reuse-test && cd reuse-test                     
Initialized empty Git repository in /Users/danielmorandini/reuse-test/.git/
danielmorandini@jecoz reuse-test % git submodule add https://github.com/kim-company/pmux.git
Cloning into '/Users/danielmorandini/reuse-test/pmux'...
remote: Enumerating objects: 27, done.
remote: Counting objects: 100% (27/27), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 421 (delta 5), reused 20 (delta 3), pack-reused 394
Receiving objects: 100% (421/421), 2.29 MiB | 4.13 MiB/s, done.
Resolving deltas: 100% (194/194), done.
danielmorandini@jecoz reuse-test % cd pmux 
danielmorandini@jecoz pmux % reuse lint
# SUMMARY

* Bad licenses:
* Missing licenses:
* Unused licenses:
* Used licenses: MIT
* Read errors: 0
* Files with copyright information: 22 / 22
* Files with license information: 22 / 22

Congratulations! Your project is compliant with version 3.0 of the REUSE Specification :-)

Now make a step back and check from the parent git repo.

danielmorandini@jecoz pmux % cd ..
danielmorandini@jecoz reuse-test % reuse lint
# MISSING COPYRIGHT AND LICENSING INFORMATION

The following files have no copyright and licensing information:
* .gitmodules
* pmux/README.md
* pmux/examples/config.json
* pmux/go.mod
* pmux/go.sum


# MISSING LICENSES

'MIT' found in:
* pmux/.gitignore
* pmux/.goreleaser.yml
* pmux/cmd/root.go
* pmux/cmd/server.go
* pmux/cmd/wrap.go
* pmux/examples/list-sessions.go
* pmux/examples/mockcmd/main.go
* pmux/http/pmuxapi/handlers.go
* pmux/http/pmuxapi/router.go
* pmux/http/pwrapapi/router.go
* pmux/http/pwrapapi/server.go
* pmux/main.go
* pmux/makefile
* pmux/pwrap/pwrap.go
* pmux/pwrap/pwrap_test.go
* pmux/pwrap/ucb.go
* pmux/tmux/tmux.go
* pmux/tmux/tmux_test.go


# SUMMARY

* Bad licenses:
* Missing licenses: MIT
* Unused licenses:
* Used licenses:
* Read errors: 0
* Files with copyright information: 18 / 23
* Files with license information: 18 / 23

Unfortunately, your project is not compliant with version 3.0 of the REUSE Specification :-(

Hint

I'm not a python fan and I did not dig into the code, but it looks like reuse is not taking into consideration nested .reuse folders.

Context

OS: Darwin jecoz.local 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64
reuse version: reuse 0.5.2

@carmenbianca
Copy link
Member

reuse 0.5.2

This version is outdated. Can you try with a newer version? Newer versions of reuse should—by default—completely ignore submodules unless you do reuse --include-submodules lint. In which case it might still not recognise nested .reuse folders, but I'm not sure.

@dmorn
Copy link
Author

dmorn commented Feb 7, 2020

Hi @carmenbianca (I notice now I heard you speaking at the SFScon! 😊), yes you'r right: I updated the tool, now I'm running version 0.8.0, and it does not check submodules. --include-submodules fails as above though.

@mxmehl mxmehl added this to the 0.14.0 milestone Apr 27, 2021
@mxmehl mxmehl added the bug Something isn't working label Apr 27, 2021
@mxmehl mxmehl removed this from the 0.15.0 milestone Jan 22, 2022
@mxmehl mxmehl changed the title linter does not support git submodules properly linter does not support dep5 of git submodules May 6, 2022
@mxmehl mxmehl added this to the Backlog milestone May 6, 2022
@hoijui
Copy link
Contributor

hoijui commented May 19, 2022

I am running latest git version of reuse as of today (exactly v1.0.0),
and it does check git submodules again, and in my case fails because of this.

@hoijui
Copy link
Contributor

hoijui commented May 19, 2022

What would we want to happen, optimally?

  1. search for all sub-paths .reuse/dep5, instead of just in the project-/scan-root?
  2. If we are in a git repo, check if a .reuse/dep5 exists for each git sub-module?
  3. dep5 does not seem to support an import functionality, where one could link to sub-modules dep5s from the root one.

@Tachi107
Copy link

dep5 does not seem to support an import functionality, where one could link to sub-modules dep5s form the root one.

I'm not sure I understand this point, could you explain it a bit further? Why would it be useful? (by the way, the current dep5 specification is available here)

@hoijui
Copy link
Contributor

hoijui commented Jul 28, 2022

I am not sure it would be good to use (my feeling is rather, not so much, as it would be too manual/work intensive), but as it seems not to exist, I would say it makes little sense that we go deeper into it.
What I mean is something similar like you have in programming languages, like import in python, or #include in C/C++.

@buxtonpaul
Copy link

Not sure on the status of this, but going back to the original posters problem.
Given a sub-directory that is reuse compliant it would be useful if when running the reuse tools on a parent project for the license information be properly propagated up.
This would seem to me to be a common use case where for example a large project has dependencies on several other projects. In an ideal world those dependencies would also be using reuse and developers of the parent project should only need to declare license information for their own files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants