I wrote my nRF24L01+ Tutorial some time ago and it seems that the Rf24 library author @TMRh20 has modified the library in a way that is not backwards compatible. I have already made one change to my Tutorial to make it compatible but it now seems there is another problem.
I’m really furious that someone would change his library so that existing code fails and I don’t plan to spend my life updating my Tutorial (in which I invested a lot of time) every time @TMRh20 has another incompatible idea.
What I would like to do is put into the library manager the older version of the RF24 library that works with my Tutorial code giving it a suitable name so it is easily identified. That way both versions can co-exist and @TMRh20 can make whatever changes he wishes without screwing up my Tutorial.
I have the code for the older version which I downloaded from Github back when it was current. What is needed in order to put that version into the library manager?
maybe one easier solution is to put the whole old library in your working folder and in your code, when you do the #include use double quotes “…” instead of angle brackets <…>. That should grab the local version - unless the IDE is doing something “clever”
One fair thing to do would get the author to approve this as this risk creating some dilemma for newbies not knowing what to download.
I understand the frustration because of the amount of work you put into your tutorial, but what's a tutorial worth if you are stuck in the past with it and can't use the latest and greatest version of the library and you learn something not applicable? May be some of the stuff that used to work were side effects of bugs that have been fixed? life is an eternal restarting..
Maybe raising backward compatibility issues in the author's GitHub would help address those
You think he did it on purpose ? What did he do ?
Of course I don't think he did it on purpose. But it was very thoughtless. He made an updated version of his library that is not backwards compatible and saved it under the same name as the earlier version. He could so easily have given the new version a new name so it could coexist with the older version.
This is at least the second time @TMRh20 has done this. The first was when he created an updated version of the ManiacBug version and did not change the name then, either. And to the best of my knowledge he is aware that of my criticism about that.
What I do is
i) rename the Arduino libraries dir to say libraries_newBroken
ii) create a new empty Arduino libraries dir
iii) download the old version to the new libraries dir. Usually in the Arduino library manager you have a drop down list of the versions to choose from
I can then swap between versions by just renaming the libraries dirs
I can then swap between versions by just renaming the libraries dirs
A good technique in general, but not really relevant to this conversation.
However, if there is a version of the TMRh20 RF24 library in Library Manager that is compatible with Robin2's tutorial, it might be reasonable to just specify that version must be used in the library installation section of the tutorial. The only problem with that is the Arduino IDE will periodically prompt the user when there is a newer version in Library Manager of any of the installed libraries. That's generally very useful, so it's not a great solution to tell people they need to shut off that notification.
It is unfortunate when this happens especially when an API is changed with the effect of breaking a lot of existing code. It is bad enough when untested changes are released, like has apparently happened with the IR library recently. There, however, there is at least the hope that existing code will again work at some point. One lesson, when you write a tutorial or application, is to specify the exact library versions used and state that a troubleshooting step is to revert to those versions.
It is an unfortunate feature of community produced code, that quality issues can be given a low priority.
On that theme, I, personally, would like to see some sort of ranking system where libraries for commonly used peripherals / devices can be given an EBay-like reputation or score by its users, with the facility for extensive comments. This would also help new users who are baffled by the choice of libraries for, say, the DS3231, LCD1602 etc. etc. by weeding out the poorer contributions.
Having said all that, the obvious advantage of such community produced code is price and features.
For the purposes of Library Manager, the repository name is irrelevant. You can name the repository any way you like. It's the value of the name field of library.properties that must be unique from any of the existing libraries in the Library Manager index.
This library has complex ramifications and includes many other files. If you change the name of the library, does the IDE guarantee that all files included by this new library will come from the same directory or is there a risk it gets some from the other (updated version) directory?
That’s may be just me but I would not invest my time to learn about something with an obsolete tutorial that anchors me in the past. So From an peace of mind standpoint I still think submitting bugs for non backward compatibility and see what the author has to say would be a good first step. If he can address those then your tutorial will still work AND users don’t have to worry about which library to use. Seems the right course of action to me.
So if you have a version of the library in a folder named "RF24" and another version of the library in a folder named "RF24-Robin2", then, assuming they both have the same architecture match score, an #include directive for "RF24.h" will cause the "RF24" library to be selected.
A workaround for that can be to add a matching header file to the library (RF24-Robin2.h in this example). That "wrapper" header file can just contain an #include for the true primary header file:
As for the other files in the library, the include paths are first checked for the header files, and the Arduino library discovery process is only done when the file is not found there. So as soon as the library is selected by the discovery process, the other files of the library will always get priority over files of other libraries that haven't already been added to the include path by the discovery system. So this is really only a concern in the event the library has multiple primary header files that might be used in the #include directives of sketches or other libraries. In that case, you can simply add unique "wrapper" header files for those as well.
I'm really furious that someone would change his library so that existing code fails and I don't plan to spend my life updating my Tutorial (in which I invested a lot of time) every time @TMRh20 has another incompatible idea.
No doubt one possible implication of the library 'update' is a great many other tutorials and destructables out there will stop working and we can guess where the queries will be raised .......................
I'm still really angry about this even after a good night's sleep. I don't plan to upload anything for at least another 24 hours. This problem has actually undermined my enthusiasm for the whole Arduino system.
My present thinking is that the library manager system is fatally flawed if it accepts revisions that have the effect of breaking code that has been working since August 2016. In saying that I am not implying that there is a simple fix.
I think the only effective solution is not to use the library system at all and simply copy the library code alongside the relevant .ino file and use the style #include "myRF24" That way, not matter what changes occur to the library the project code will be protected. But even that is not simple due to the way the Arduino IDE searches for libraries - AFAIK it is no content to limit its search the the local directory even when the library is in quotes.
Most all of the queries in the Arduino forums seem to be from users who cannot get their nRF24L01s to work at all. The quality of these modules from far East suppliers does not appear to be good.
I had aquired around 10 modules and after a lot of playing around eventually worked out that 4 or 5 of them were dead.
Perhaps a completly standalone TX and RX sketch would be useful. That would allow users to work out if their modules were working and the standalone sketch would then be independant of present or future chnages to the library.
Without the author work and the sheer existence of the Rf24 library in the first place your tutorial would not have existed. The library (and your tutorial I’m sure) has helped tons of enthusiasts around the world achieve cool stuff with their nRF24 components (when they work).
I totally hear and get the frustration and sympathize but intellectual honesty would also require to dig into the why and clearly qualify your claims and assess if the way you wrote the tutorials in the first place was not flawed in some way, making second guesses or relying on undocumented features or bugs that had the side effects of getting your stuff to work. Or need to see if it has indeed been intentionally made non backward compatible for whatever reason.
That’s why I think the only way of getting to the bottom of this is
document what you found is not backward compatible.
submit bugs in GitHub to the author
see what he has to say
Dialogue and constructive approaches with everyone sitting around the table are always better in my humble opinion than half baked solutions. As a developer I’d prefer one great RF24 library than 10 different ones...
On the topic of libraries - it’s an open world and that has been one weakness of the open source community for ever. There is by design no Uber authority maintaining the global coherence of the full environment. Arduino offers bundled libraries and if you wander outside that realm you are somewhat on your own. Commercial vendors like adafruit are trying to maintain coherence of their libraries for their components and would avoid breaking API compatibility (yet could still mark some as obsolete or deprecated and going away at some point) but You are the ultimate designer of your development environment by choosing versions of the libraries, IDE, compiler flags,...