Support .in files (or just cmake.in)

[henryiii]

A common pattern is a .in file, which should be identified as the inner type, that is, MyConfig.cmake.in should be a CMake file, and pytest.ini.in should be an ini file, etc. AFAICT, this is not currently supported?

[asottile]

the problem with .in is it usually implies some type of preprocessor, and almost always the preprocessor templating is incompatible with the end file format (you wouldn't lint a foo.py.in file the same as a foo.py files). Additionally, .in could imply any sort of preprocessor (it may be autotools, it could be some simple sed, jinja, who really knows!)

As such, I don't think this should be implemented, what are your thoughts?

[henryiii]

In my case, I want to identify files for formatting, so I definitely want to pick up cmake.in files and format them too. However, for a linter, I'd like to be much pickier, you are right. Would it be possible to add a modifier for file types? Such that X.in is a X file with an .in extension?

Something like this:

identify.tags_from_path('/path/to/file.py.in')
{'file', 'text', 'python.in', 'non-executable'}

(maybe a 'in' too)

[asottile]

at that point I would probably revert to using types: [file] and implementing what you need in the files: regex

[henryiii]

CMake-format is explicitly supporting *.cmake.in files in it's next release, so it would be very nice to be able to elegantly identify these (it actually caught me by surprise that they were not being picked up by default, since they are a very common file type in CMake).

(And an explicit regex is what I'm currently doing):

   types: [file]
   files: (\.cmake|CMakeLists.txt)(.in)?$

[henryiii]

By the way, .cmake.in's might be a bit special here, since they are a very common CMake file type (pretty much every package has a *Config.cmake.in) and very well defined, with just one additional bit of syntax. Unlike most other cases, I'd even expect the pre-commit extension for cmake-format to find cmake.in files by default, actually. But I would think a general solution here would be better, as it would give the ability to easily identify other .in types, but I mostly care about cmake.in at the moment.

[henryiii]

(Sorry, meant to comment on the other issue - can update to say that the most recent release of cmake-format does already support cmake.in)