Guys, like I said, the project is in early status! The tests so far should therefore be understood as a proof of concept. Maybe I could have made that a little clearer in my initial post.
In any case, thanks for the feedback! 😃
Categorizing the messages would certainly also make sense. Like: critical
, warning
and information
.
@sdetweil said in Automatic checking of all MagicMirror² modules:
things that depend of features no longer available in the os like vcgencmd
Is vcgencmd
really no longer available? I don’t have the current OS version yet, but I can’t find any information about removing it in the documentation:
https://www.raspberrypi.com/documentation/computers/os.html
If so, what would be the alternative?
and omxplayer
Thanks. This is a solid suggestion, just like I was looking for! 😃 I have added this to the check list. There are a handful of modules which contain omxplayer
.
I don’t have a concrete approach for your other suggestions.
@MMRIZE said in Automatic checking of all MagicMirror² modules:
There are also wrong checks. (For example, MMM-ModuleMonkeyPatch …
Ah, I used the module to provoke errors manually. I forgot to remove the folder 🤦. The checks themselves are not wrong.
dependency checking is information ordinary users …
Ordinary users are not the target group for this project. The project collects information about modules, the developers can do whatever they want with the information (even ignore it).
For the core developers it is certainly sometimes interesting (e.g. before breaking changes) which modules still depend on a core functionality.
it would be better to reveal the last update date or the number of unresolved issues to guess the module’s activation level or popularity
Those are good points, thank you! I put them on the to-do list.
Or, if you are going to parse package.json anyway, I think it could be used to organise installation methods, etc.
Yes, I had already thought about parsing the package.json. What do you mean by “organise installation methods”?