bayviewboom:
No, it's not simple for the user when the user gets warnings about multiple copies, or the user can't compile. The first post in this thread is one of several related user-posts.
It usually is simple for the user. These issues typically don't occur unless they did something to mess up their Arduino environment.
What can be difficult for users, when things do break, is to figure out how to fix their environment.
In nearly all the cases I've seen over the years where things get wonky with multiple copies of a library, the user did something to cause it.
(I say "nearly all" because I'v seen a few cases where a bad developer screwed up their github repository and it confused the IDE library manager)
The way this tends to happen is that the user did something incorrectly, like manually installing a library incorrectly, or installing the library in multiple places, or installed multiple versions of the same library or installing multiple versions in different places.
No, the updater-process does that. That has nothing to with priorities. If only one single copy of a given version were allowed, that version could be updated even without a priority system.
It is much more complex than that. There are issues related to multiple copies of the same version of a library installed (happens from the user incorrectly installing it multiple times in multiple locations), the issue of multiple copies of a library, regardless of version, being installed, and then there is the issue of how to handle different MCU architectures for a library.
A single library for multiple architectures was the original approach that the Arduino.cc team had proposed for Arduino 1.5 libraries to support multiple architectures.
i.e. a single library that supported all architectures.
This way of trying to do things does not take into consideration how multi-platform libraries would be implemented and maintained in the real-world, particularly for 3rd party Arduino libraries and cores.
There were a few of us that lobbied heavy to the Arduino developers to NOT have a single library system.
(We lost and the original 1.5 library system was a "all in one" library design)
A priority system makes more sense when trying to solve issues like how to handle libraries across many architectures.
Consider this, if you have a system that has a single library with multiple architectures, who owns it? who maintains it?
How do you get support for your new core into it?
Is it done with ifdefs, is it done with a separate tree for each architecture?
The Arduino team had decided to use separate sub directories for each architecture rather than ifdefs all within a single library.
While this sounds nice and makes the code for each architecture cleaner/simpler looking , it makes maintenance extremely difficult as now anybody that wants/needs support for their 3rd party core must get their code into the tree for the single library which is controlled by someone else.
It also means that if there is a bug, or enhancement, all the sub directories for each architecture within the library tree must be updated.
In the case of a 3rd party library, you have to go to that third party library owner, and ask to get the code added/updated to their library/tree, or fork the library to include your code, and then try to convince users to install your fork rather than the original source for the library.
This does not scale.
Trying to use a "all architectures in one library" quickly becomes completely unmanageable.
It took a while, but the Arduino.cc deveopers finally saw the light and went away from the "all architectures in one library" using subdirectories for each architecture approach and added support to what you see today where there is a priority of multiple places that the IDE will look for a library which allows 3rd party core developers to ship their own version of the library with their core.
While there are still some issues (serious issues) with the current priority system used by the IDE for library selection, it is much better than having a single "all architectures in one library" approach.
This allows a 3rd party core to ship its own version of a library that it can update/modify/test/verify independently of another cores library as well as offering the user the ability to override libraries with their own personal version.
And for the most part, most users do not ever see or run into these issues unless they have done something like improperly install libraries (like installing multiple versions a library directly from zip file obtained from a github page) or are using a machine that has multiple versions of the IDE installed on it.
Most users don't do either of these, so they don't run into some of these remaining issues.
One of the way things went south with the priority system and the library manager is that the IDE starting using the user sketchbook for its own IDE bundled library updates.
For example, it may want to update LiquidCrystal or Ethernet independently of the IDE, so it puts the updated IDE bundled library in the users sketchbook directory.
That is just plain wrong! Not only is it potentially stomping on a users personal library that he may already have there, but it can break other versions of the IDE that might be installed on the same machine since the updated library may not run on older/different versions of the IDE.
The original idea for IDE bundled library updates was to update IDE bundled libraries "in place", which is the correct thing to do; however, the reason that this was not done was that there was a concern that the user may not have the needed permissions to do this.
That was a valid concern, however the solution of switching to just using the sketchbook library area was the WRONG solution to this.
IMO, this wasn't really a problem as it could have been as simple as doing the updates in place and updating documentation to say that updating IDE bundled library requires having the same permissions that were used for the original install.
Another thing that is missing from the current IDE library priority system is using a "libraries" directory under the sketch directory.
This could be very useful. This directory location should be of the highest priority. It would allow things like overriding and specifying specific library code for an individual sketch.
It would also allow bundling and entire project, sketch and all needed libraries into a single tree.
Another thing that is missing from the IDE library manager is a way to remove sketchbook libraries.
Arduino.cc developers have resisted this feature request for years. I have no clue why.
Having this ability could help some users clean up the mess they made by installing multiple versions of libraries.
It would not be that difficult to implement, but the dev team is pretty insistent on not doing it.
Another area where the library manager could help users from getting into trouble would be to have some better handling of zip files obtained from github repositories.
The issue is that github creates "release" zip files with a name and sub directory that matches the library name and tag
"libname-tagname.zip".
If the IDE library manager is used to import the library from that zip file, you end up with a subdirectory named:
"reponame-tagname" instead of "reponame". So users that do manual installs using zip files from github end up with incorrectly installed libraries.
For example:
if a hd44780 library in a github repo name of hd44780 has a tag of 1.1.0 the github zip file will be named hd44780-1.1.0.zip and the top level directory will be called, hd44780-1.1.0
The problem with this is that this will create a sub-directory named "hd44780-1.1.0" instead of just "hd44780" in the users sketchbook area and most users don't go back and manually rename it correctly.
This is an incorrect library installation. If the user does this again in the future to update the library, they end up with multiple versions of the library incorrectly installed in their sketchbook area.
Note that this is only an issue when using zip installs with zip files from github.
If the library can be installed & updated using the automated capabilities in the IDE library manager, this will not occur.
What makes this zip installation a problem is that, as mentioned earlier, the IDE does not have a way to remove libraries.
Users may realize the trouble they have created, but do not know how to remove previously installed libraries.
IMO, adding the ability to remove libraries from the IDE, and making the IDE zip file installer smarter to know how to trim github filenames names to create proper Arduino library sub-directory names, would go a long way to help preventing much of the user "multiple" library issues I've seen.
--- bill
