licenses / lice

Generate license files for your projects
BSD 3-Clause "New" or "Revised" License
506 stars 38 forks source link

Infer language only on the basis of file extension #27

Closed Yonaba closed 11 years ago

Yonaba commented 11 years ago

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.

alex179ohm commented 11 years ago

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 > whatdoyouwant

in 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.c

write 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 foo

does 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.hpp

So, 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.c

write 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 foo

do nothing, foo is not a license.

jcarbaugh commented 11 years ago

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.

Yonaba commented 11 years ago

@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 ?

$ lice -f foo.py --> Generates foo.py
$ lice -f foo  --> Generates foo.txt
$ lice -l py --> Generates license in python style on shell output
$ 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++.
jcarbaugh commented 11 years ago

@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!

Yonaba commented 11 years ago

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.

alex179ohm commented 11 years ago

@jcarbaugh

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
LICENSE

when both language and file are specified, .txt extension is appended:

$ lice -l txt -f LICENSE
$ ls
LICENSE.txt