With so many libraries how can you tell which you should use

I've seen many libraries which on the surface have the name but looking into them they are obviously different in different ways. When the library isn't listed for a project and I just have the #include info how can you really tell which library you need? A perfect example is JSON_parser. One library is Json_Parser, one is JSON_Parser and the content is different. Others have the exact same case, in one of my situations I have a Adafruit_GFX library but the github version is slightly different. And the same situation would apply for hardware specific libraries that call a certain file.

I'm fairly new to this and i'm just looking at things and trying to reverse engineer some of the software to understand how everything works.

Thanks much,

Dave

Most libraries come with a number of examples that exercise the library. Look at those examples and see if any of them are similar to your needs. If one is, try modifying it to see if you can get the modified program to do whatever it is you need. If not, just keep looking.

I am looking at example sketches which are calling for a library but it doesn't say anything other than "I used this library" without a link or anything of the sort so I go to github to search for the library but am unsure if that is the correct library as I'll sometimes get random errors while compiling making me think it isn't the actual correct library.

As an example, one sketch is calling for Adafruit_GFX but I now see I have v 1.0.2 and there is a github version of 1.1.5. Would I be best served to install 1.1.5 unless something specifically states it wants 1.0.2 or otherwise? I don't really see a version history readme with what was changed so I'm a bit confused there.

Dave

Most of the time the newer version from the same developer are backward compatible unless stated so. So get the latest version possible.

Try finding libraries that are maintained - modification in recent months is usually better indication than last update 5 years ago (although some will just work fine)

Some things changed when the IDE went to version 1.0 that render very old library not appropriate (but usually not too hard to fix)

On github, there will usually be a history of changes. "Forked xxx to optimize for arduino. Make work on arduino mega. Add support for arduino zero." And similar...

Thanks much. There are so many little things to learn on this. So generally speaking a different dev won't intentionally modify for self use or use the same name as another package and publish intentionally? What initially confused me was a package I was looking for which called for a JsonParser.h file and I found a few and one was JSONParser.h and obviously didn't work. I then looked further to find JsonParser.h. At this point I found out that these scripts are very much like linux/Unix in that everything is case sensitive.

a different dev won't intentionally modify for self use or use the same name as another package and publish intentionally?

"intentionally", probably not. Although the github structure does seem to encourage winding up with "westfw/Audiolib" forked from "Adafruit/Audiolib" forked from "Arduino/Audiolib" - ie libraries that are "properly derived" from elsewhere may end up with the same name even long after there has been a lot of divergence.

And nothing stops duplication of names in ignorance. How many different names can you think of for a JSON parser library that you wrote from scratch and decided to let other people use? That's why long-time forum users can get so annoyed when "newbies" post questions like "I'm use the JSON Library and it's not working right", without including any link to exactly which JSON library they are actually using (after all, there is no official Arduino JSON library...) (hint, hint...)

The library forks can get really confusing. On GitHub forks it shows "forked from" under the repository name but sometimes the original repository is no longer maintained and one of the forks is where the active development is occurring so you need to figure out which of the forks is the best one. You can easily see the differences between the various forks by looking at the network graph, accessed by clicking on the number next to the "Fork" button. Unfortunately many people create forks just to have a backup of the repository and once you get too many forks GitHub won't show a network graph so this feature is not available for the most popular projects but I haven't encountered that issue with any libraries. Adafruit-GFX-Library has 484 forks!

In a perfect world the owner of an abandoned repository would pass on the flame by noting the URL of the active fork in the documentation and owners of forks that are significantly diverging from the original with no intention of pushing those changes back to the original would change the name but that doesn't always happen.

For any of the adafruit libraries, I'd use the IDE library manger to install it right from the IDE GUI.
Adafruit is good about keeping their libraries up to date in the library manager.
You won't have to mess with github, zip images or manual installations at all, which can be a pain if Windows is involved.

In fact, I'd look in the library manager before I'd go off looking at github repositories particularly since the library manager is a relatively new feature in the IDE so any of the libraries that are in it are unlikely to be extremely old.

My general view is that any library developer or maintainer that is decent will take the time and effort to add the library into the Arduino IDE library manger since the library manger makes it so much easier for users to find and install.

--- bill

pert:
In a perfect world the owner of an abandoned repository would pass on the flame by noting the URL of the active fork in the documentation and owners of forks that are significantly diverging from the original with no intention of pushing those changes back to the original would change the name but that doesn't always happen.

But sometimes there can be disagreements.
I've run into situations where a library author/owner will refuse to accept some updates.
In that case in order to preserve existing code, you don't really want to change the name so you are stuck with having to leave the name the same but clone the alternate forked repo or install the alternate library directly into your sketchbook area.
There is a situation like this right now with the Ethernet library as well as several others.

I have unsuccessfully tried to get the Arduino team to consider modifying the way the library manager works to allow each library to specify its update repository inside its directory either in the .properties file or in a .json file rather than only use a single master list of all the libraries.
If the library directory itself contained the paths to the repository for that library, once a library was installed, the library manger could do the updates from the repository indicated by the library rather than the repository maintained in the master list.
That way users could install a library from anywhere and once installed, the library manager could do the updates.

This would solve the abandoned or alternate library problem as well as users could simply install the alternative library and get updates from the repository indicated by the library - including if its name happened to match a library in the master list.

This methodology would also allow multiple libraries with the same name, should the arduino team decide to allow that. Since the master list would simply be a list of libraries that can be installed and where they can be installed form. Multiple libraries with the same would no longer be an issue.
Once installed, the library itself points to where to get future updates for that library.

Another big benefit for the Arduino maintainers is that their load could potentially be reduced in that users could install 3rd party libraries from a repo and the library author would not have to work with the Arduino team to set it up into the master list. That process is ridiculously manual right now.
i.e. users could do a install from zip image and magically the library would be added to the library manager and all future updates could be handled by the library manager - all with no manual work on their part to add the library to the IDE library manager master list.

--- bill

In fact, I'd look in the library manager before I'd go off looking at github repositories

Oh yes. In general, get the most recent library from the most responsible source, and if it doesn't work with old example code that you've found on the net, try to figure out why (possibly asking, here) and update the sketch rather than reverting the library to older versions.

Using github's features is more useful for figuring why and how things have changed...

I've run into situations where a library author/owner will refuse to accept some updates.

Oh yes, again! "most responsible" source doesn't necessarily mean "the one with the most features." Some owners are more concerned with stability (or whatever) than new features, or faster implementations.
For example, Arduino Staff has said that they don't intend to update the version of the Optiboot bootloader that is shipped on many AVR Arduinos: "there are too many products using the version we use, and updating would create Havoc." I can see that.
I maintain a separate (official, but not-Arduino) github repository for Optiboot. It's got a bunch of new features since the Arduino version, supports more chips, etc. And yet I am hesitant to accept requests to add new features that I see as risky or "destabelizing" (like the addition of a function to allow sketches to write to flash.)
Several other people have forks of THAT optiboot branch, where they've added some of the features that I haven't, and are distributing them (part of the AVRTiny Board support, for example.) That's fine. (except for the guy who wants to remove the version number. That's CRAZY! Even if people aren't so careful about updating it.)