Infer language only on the basis of file extension
Yonaba opened this issue · comments
Something have been bothering me since a few days, then I am opening the debate.
Actually, I have the feeling that the -l (for language) and -f (for output filename) can lead to potential confusions.
For instance, with the actual implementation, what happens with this ?
$ lice -l py -f test.c
Well, it might output something. But this rather means that there is some precedence rules involved, and the user should learn about them before using lice.
And what if I want to generate an .hpp file with a license header ?
$ lice -f foo.hpp
Yes, that one might work, but using the -l attribute would not. Because .hpp is a c++ source, but on the other side, c++ language is associated with different extensions (.cpp, .hpp, etc.).
And, if I try:
$ lice -l cpp foo
Do I get a foo.cpp file ? What If I want a foo.hpp file ?
The point is, there is some inconsistencies here. In my humble opinion.
Then, I was thinking on inferring the language only on the basis of filename extensions. That would mean we should completely give up the -l attribute. Then, on the basis of the extension of filename to output, the comment style would be inferred. In case there is no filename extension specified, then it would default to simple text (txt) style.
Thoughts ?
PS: Actually, I did not try these commands (I am not familiar with Python), but I am just making assumptions reading from the code, so I may be wrong on some points.
I Agree with you more document is needed.
A language argument (-l) was added before file extension detection.
-l argument is important to format license in stdout and allow user to use lice in shell environment.
es.:
$ lice -l py > whatdoyouwantin this mode user can write license to file descriptor, send license to other processes or write formatted license in a socket.
remove language argument eliminate this future. (user can use formatted license only with files)
now lice have this behavior:
it read language argument, then it read file argument and if file extension exist, language format is changed else -l format is used.
This implementation is the trouble which cause:
$ lice -l py -f test.cwrite a C formatted file and not a python formatted comment in a c file.
cpp, hpp, c, cc, h and m file are associated at C99 multiline comment style:
/*
* C99 style comment
*/I've associate all c-family languages to C99 style.
$ lice -l cpp foodoes nothing because foo is not a license.
but if you want a foo.hpp file have different choises:
$ lice -l hpp -f foo
$ lice -f foo.hpp
$ lice -l hpp -f foo.hppSo, we can change the implementation in:
lice read language argument, then it read file argument, if language exist use language else use extension (if exist else it use default language).
$ lice -l py -f foo.cwrite a license formatted for python language in c file.
$ lice -f foo.hpp write a C99 formatted license in foo.hpp file
and:
$ lice -l py foodo nothing, foo is not a license.
There is definitely a conflict here, but I think that -f should both infer and override the -l argument.
$ lice -l py -f foo.c
would generate the same thing as
$ lice -f foo.c
since -f takes precedence.
Since -f would override -l, it makes the following invalid:
$ lice -l hpp -f foo
I'm fine with that being invalid. I think you either specify a file with a format extension or you specify a language without a file, but not both.
@alex179ohm (says): -l argument is important to format license in stdout and allow user to use lice in shell environment.
Very solid point, I missed that.
@jcarbaugh:
Well, I am totally fine with -f taking precedence.
So, can we actually state the following ?
- The option
-fhas higher precedence. The filename should go along with the file extension, from which the language is inferred. When no extension is provided, language defaults to plain text (txt) style.
$ lice -f foo.py --> Generates foo.py
$ lice -f foo --> Generates foo.txt
-lis intended for shell output. Then it has lower precedence, compared to-f. Therefore, when provided,-fshould be missing:
$ lice -l py --> Generates license in python style on shell output
- When both
-land-fare provided with values, in case there is an extension matching the value passed to language, it should be considered valid (and only in this case). For instance:
$ lice -l hpp -f foo.hpp --> Generates foo.hpp
$ lice -l c -f foo.c --> Generates foo.c
$ lice -l lua -f foo.lua --> Generates foo.lua
In any other case, it should be considered as a conflict and an error should be reported. Examples:
$ lice -l hpp -f foo --> Filename is resolved as 'foo.txt', but '.txt' does not match '.hpp'
$ lice -l c -f foo.lua --> '.lua' does not match '.c'
$ lice -l cpp -f foo.hpp --> '.hpp' does not match '.cpp', even though they both refer to C++.
@Yonaba I think this sounds like a great approach.
My first inclination would be to let the -l fail silently when -f was present, but you are definitely correct that the warning is a much friendlier way of doing it.
The one thing I would change is to not assume a .txt extension when none is specified on -f. I usually like to name my files LICENSE, without an extension. I'd hate for lice to assume and add .txt. Other than this small thing, I think this approach is ready to go!
Awesome, i'll take it into account and make some updates to the Lua version soon.
@jcarbaugh says:
The one thing I would change is to not assume a .txt extension when none is specified on -f.
Actually, my bad, I may have stated my idea wrong. I wanted to say, when no extension is specified on -f, the license text in the output file will be formatted in plain text style. Not that the .txt extension will be appended.
I usually like to name my files LICENSE, without an extension
me too.
this pull_request ( #33 ) fix .txt extension:
when language isn' t specified the extension isn't appended:
$ lice -f LICENSE
$ ls
LICENSEwhen both language and file are specified, .txt extension is appended:
$ lice -l txt -f LICENSE
$ ls
LICENSE.txt