Main ideas for new behaviour

[johann-petrak]

Here a quick list of the main ideas for the new version:

• process a list of directories or individual files
• allow to filter files from the directories using an ignore list
• most things defined in TOML config files
• the package comes with a default TOML file:
  • additional config files can either replace or udpate the main parts
• default templates are defined in the config files but templates can be read from arbitrary files as well
• templates can have any numbers of variables to replace
• variables can be set from the command line or from the config file
• running the command requires one of several actions: remove / add / update / ensure / check
• better specify how existing licenseheaders are matched/found and how a new header is created / inserted
• updating will always replace an existing header with a newly generated one but file is only written if
  what is generated differs from what is already there
  • so no replacement of just the year any more
• the check action indicates if something would change but does not change any files
• changed files get optionally backed-up

[aminya]

I would like to be able to collect all the license headers from a project and make a LICENSE.txt file that summarizes the license for all the files.

[aminya]

Imagine there is a large project in which each file has a different license header. I'd like the script to be able to find these and list them in a file. Optionally it can group the files in a folder if the license is the same for all of them.

Output:

- folder1/file1.py: MIT license
- folder1/file2.py: MIT license
- folder2/file2.py: BSD license

Optional grouping:

- folder1: MIT
- folder2: Apache

An example of such a project that benefits from this:
https://github.com/AuburnSounds/Dplug
https://github.com/AuburnSounds/Dplug#licenses

[johann-petrak]

The main problem I see with this (and so far in general) is that this would need to not just locate the place where a licenseheader is expected or should get inserted, but somehow understand or match the licenseheader.

The new design I have in mind would first locate the lines which could be a licenseheader, based on how such a header would start, continue and end and based on what can come before it and then optionally verify it is a header by matching some regexp pattern which must occur in it.
But it would not care what is actually in there: if the action is to ensure a header, it would simply replace the current header with the target header.

For project which have several different licenses for different parts, it would be easy to run the tool for each of those parts separately, with a different license template configured.

What would be possible with this approach is some action that would collect all the different headers that occur, store each different header in a separate file somewhere and then create a file that maps the path of each processed file to one of those saved header files. But the tool cannot know WHICH license this is that would be much more effort to do properly, if it all possible in the general case.

[aminya]

Yes, what I am looking for is a license regex matcher. I think I can write my own tool for that. Since I don't need to edit the files (which this library does).

[johann-petrak]

I have actually thought about this for tool as well, but it really depends on the situation. The two extremes are: 1) just match a few regexps against all the lines of a possible header and if they all match, assume it is actually a licenseheader block. 2) use the license header templates to generate a regexp pattern and match specific templates only.
1 can find unknown headers more easily (high recall), 2 will only find very specific instances (high precision).

I think for a generic tool to add/update headers, 1 is potentially more useful and this is what is planned at the moment.

[keiranmraine]

Feels like a separate tool

[curoky]

Hope to support the matching of the entire file name.
For example, cmake use CMakeList.txt and blade use BUILD/WORKSPACE, and make use Makefile and so on.
Then we can --additional-extensions python=BUILD,WORKSPACE.

[emschu]

Recently, I've discovered this project which is in an early stage and there are still missing some features, but it does almost the same tasks you listed here (+ Third Party dependency lists) and its approach is pretty universal regarding the list of supported languages/file types.

I just want to mention it here to avoid developing software which already exists...

[johann-petrak]

Thanks for making me aware of this, I did not know that project. I will have a closer look at it when I find a little time.

I am not too enthusiastic about this being implemented in Go and the "make" step failing and the project having no issue tracker,and the name of the project, but given that my own time to work on this project is quite limited, it is still likely a much better and reliable tool to use.

[johann-petrak]

Oh the issues have to get submitted to the main project it seems, missed that on first sight