Improve documentation on libraries out there

Hey, I just spent hours trying to find a good driver for an I2C 2004 display that didn't come with anything bt the part numbers on the chips, and went down the wrong road many times.

I finally found what is clearly the best library, why is it not in the official list of libraries on the website? There are tons of them, including some that have not been worked on for 3 years and say they are moved to places that return 404 messages when you click the link. None of the other ones I found worked properly, having major bugs.

How can I get it added?

https://arduinoinfo.mywikis.net/wiki/LCD-Blue-I2C#LCD_Displays_.28Blue_and_Yellow.29_with_I2C.2FTWI_Interface

Your post was MOVED to a more suitable location.

why is it not in the official list of libraries on the website?

isn't it that one?

https://www.arduino.cc/reference/en/libraries/hd44780/

you need to be at ease with GPL V3. that's in my view the only drawback of this library (as opposed to the more liberal licensing terms of the GNU Lesser General Public License (LGPL), MIT, modified BSD, Apache, etc..)

1 Like

If you can share the links to them, I'll see if I am able to correct that.

LiquidCrystal I2C - Arduino Reference is the one that hasn't had a commit in 3 years. The link on the github page which says it points to the new location returns a 404. It appears to work, however, so it belongs somewhere, but I think there needs to be 3, not 2 levels of classification, not "official libraries" and "a pile of half working code" but "official libraries" "not official but still good stuff" and "pile of whatever code".

I appreciate it is a lot of work to maintain such a thing, that is why I post on the forum at least. Not much but it's not a wiki anymore. It used to be. I don't know the real reason they changed. Fro the forum posts it looks like the reasons they gave were not the real reasons.

You are correct, upon closer inspection, the library is in the pile of half finished projects. However it's because of the cryptic name that I did not see it. Also even the initial document summary blurb thing is quite messy and it didn't sound like it was a working piece of stuff yet.

It should be edited to be a summary, not this big list of technical features, which as far as the user at this stage knows, may or may not work. Usually these projects that start by extolling every tiny technical feature don't work very well... this is an exception, very well done whoever did it, I would send you some crypto in thanks if I could. That's another thing for the community to work out.... Always lots to do.

Many thanks.

Thank you for providing that link.

I see there is already a report about it here:

but no response from the maintainer of the repository, so unfortunately it doesn't seem there is anything that can be done to resolve that particular issue.

Maybe you're already aware, but just to be sure, the library reference pages under the category links with the counts on this page:
https://www.arduino.cc/reference/en/libraries/
are automatically generated from the Arduino Library Manager index. Although all the official libraries are in there, anyone can add any library to the Library Manager, so there are thousands of 3rd party libraries that the Arduino organization has no involvement with.

It certainly would be nice. Unfortunately, this can be a very difficult thing to do.

There are close to 4000 libraries, and more coming in every day. A couple of years ago, I did a survey of Arduino libraries on GitHub that indicated there are at least 10000 unique libraries! Now consider that doing a single evaluation of each library is not sufficient. You must check every new release, which multiplies that 10000 number. So this is essentially impossible to do via a concerted human effort.

The next thought is to automation. Unfortunately, this can also be difficult to achieve. The reason is because each library may have very different dependencies and compatibilities. So if you went through and compiled ever example sketch of every library for the Uno, you would get a huge number of errors for perfectly good libraries, either because they are not compatible with the Uno or because they required some other libraries be installed. So the only way to do that would be for every library author to carefully define the compatibilities and dependencies of their example sketches in a machine readable format. I have been working for years to advocate for just this as it applies to continuous integration systems, which has culminated here:

However, I have not yet observed widespread adoption of these practices, and what I have seen is often not properly maintained, resulting in it breaking down over time, or never working properly in the first place.

More promising is that there are some basic validation checks you can do that are universally applicable I have been working on that sort of thing in parallel to advocating for the "smoke test" sketch compilation CI approach. That work has culminated in this:

The Arduino Lint tool can be automatically run on every Arduino library (in fact every Arduino project of any kind). There is actually already a more minimal version built in to the Arduino Library manager indexer, which rejects any release that doesn't pass the basic validations. Just imagine what you'd find if that weren't in place!

With Arduino Lint, in addition to the checks for essential compliance with what makes a valid library, there are also dozens more checks for best practices which might only generate a warning rather than an error (depending on how you configure it). So this could offer the possibility of going beyond the current valid/invalid to a graded system of something like optimum/valid/invalid. That could provide the users with more information on the quality of the library, and also encourage library authors to step up their game to get the gold star classification.

Another option would be "crowdsourced" information. We already have some stats available from GitHub to judge the popularity of a library. People can "Star", "Watch", and "Fork" GitHub repositories, and the count of each is shown on the repository page (as well as being accessible via the API). I regularly use this information when I am evaluating whether to use a given software project. You can also see how actively developed the library is, as well as the bug report and pull request count.