adding nrf24l01 driver

[2bndy5]

finally got around to doing this PR. The last page in the sharing in a bundle walkthrough had something about modifying a docs/drivers.rst, but I couldn't locate the file (outdated info?).

let me know if there are some changes that still need to be made. IDK if the other repo is still necessary

[2bndy5]

reading through the build log, and I don't see the rf24.py/mpy file anywhere. How do I address this?

[ladyada]

not sure what you mean by rf24.py/mpy - your release has files in it?
https://github.com/2bndy5/CircuitPython_nRF24L01/releases
so that looks right
we deleted our repo that was forked, to avoid confution

[2bndy5]

the travis build log for this pull request outputs
line 677: skipped path: /home/travis/build/adafruit/CircuitPython_Community_Bundle/libraries/drivers/nrf24l01/circuitpython_nrf24l01 which is where rf24.py lives, and all the files listed in the zip's lib folder doesn't have rf24.py/mpy among them

[ladyada]

you have an odd library format

use this style
https://github.com/adafruit/Adafruit_CircuitPython_LSM303
where the file is in the root directory and named something descriptive

[2bndy5]

So the bundle only accepts a module. Not a wannabe package.

[ladyada]

it works with either but i think its best if you follow the same style we have for the other ~170 libraries

[2bndy5]

OK, so I refactored the repo a bit and refreshed my fork of the bundle. Travis CI builds it perfectly and examples are running just as well.

If its not clear yet, I'm very new to contributing (anything), so I'd like to thank everyone that helped me get this done. @ladyada @tannewt @sommersoft @rhthomas @kattni , thank you for baring with me!😁

That said, I am now more confused about the differences between a python package and a module.
If I wanted to add another module (like a "FakeBLE" class) to this library: would I have to release it separately? Or could I just add it to the repo in either the root or a subfolder? Furthermore, was the structure I had at least somewhat proper for a multi-module package (like my fakeBLE branch)? And is it better to not preempt future module development for the sake of probable stagnant development progress?

[rhthomas]

No problem at all! I'm new to all this contributing stuff as well 😂 but you've made some excellent contributions, so congrats!! 🎉

[tannewt]

@2bndy5 Thanks for all of your work on this! So, a package is essentially a folder with multiple modules (aka files) within it.

I agree that you want a package in this case if you plan on adding other modules to the library.

It looks like the build is broken for some reason and is skipping packages it should include. Other libraries are failing due to this as well.

So, I'd recommend switching back to a package and we'll sort out why the build is skipping them.

[tannewt]

@sommersoft How is package_folder_prefix supposed to work for a bundle of different libraries? Looks like it broke it because there are a number of prefixes within the same zip.

[2bndy5]

@tannewt not sure what you mean by:

there are a number of prefixes within the same zip.

It looks like @sommersoft opened an issue a while ago about Folderizing examples, so its not technically broken; just not addressed yet. If that's not what you meant, the libraries with common prefixes (electronutlabs_ and sparkfun_) are actually separate libraries. After combing through the released zip files, I found that @barbudor's CircuitPython_INA3221 isn't getting included in the releases [probably] because of the same reason I brought up here (skipping multi-module packages), but that repo's examples are getting included. Looking closer at his repo's travis CI output, it is getting properly built (curiously without using the --package_folder_prefix arg?!), so it looks like the build tool fails/breaks on multi-module libraries only when building the bundle. My 1st idea of increasing the --library-depth arg to 3 didn't work (see also last commit's comment), but this issue is related to an already opened issue when --package_folder_prefix arg isn't specified (rightfully inapplicable to a bundle context).

Finally, I've decided to leave the structure of the nRF24L01 repo as is (per @ladyada's advice); as it turns out a lot of people are already downloading it from pypi (up to 900+ downloads!) in the month or so it's been publicly available. I'll let it ferment for now as the fakeBLE idea isn't panning out, and I just started school again. Maybe I'll revisit that branch during the next major school break (either winter or summer), but no promises.

[tannewt]

Ok, will merge this. We'll need to fix the folder prefix issue separately. Thanks!