Definitely, it’s the testing and modularity/flexibility that are important - space savings are just a nice bonus. The bare bones firmware performs initialization (of any devices that are included that need initialziation), then runs setup() and loop() - everything else is then plugged into that as needed at compile time.
I was skeptical too, but we've been putting down some numbers over here:
Library dependencies would be very cool! 
Is there a roadmap for when that will be available?
Unfortunately, I don’t have a precise date for when library dependencies will be available @mdma , but you pinging me did cause me to spend an hour refining the spec to get it ready for an initial implementation, 
. I’ll announce something here when we’re start working on this.
The main thing I know about library dependencies is that you’ll specify your dependencies in the spark.json exactly like you do with npm’s package.json, aka:
"dependencies": {
"neopixel": "0.2.2",
"onewire": "0.1.1"
},
Also, the initial release will also not support variable version constraints like (i.e >= 0.2.2 or ~> 0.1.1 will NOT be allowed), each library’s spark.json will lock to a particular exact version of other library.
If you have thoughts about how a lib dependency mechanism should work, please feel free to describe your thinking here too.
5 Likes
One problem I see with the dependencies is people will publish a library with dependencies and then get busy with life. If their library breaks because a dependency upreved and broke a feature (aka is now not backwards compatible), how will the Spark Libraries maintain hooks into all of these older versions? Copies of everything? Pointers to all Github commits?
I think in general people try to maintain backwards compatibility, but this is as unstructured as you can get when you are crowd sourcing all of the libraries… so deviation is going to happen more than normal.
What happens if someone deletes their github repo? I’ve already seen this happen btw… Perhaps the library could get an orphan icon, and someone can adopt it?
Is there anyway to get around the whole double name path thing… “#include neopixel/neopixel.h”? I get why it’s probably that way now, because of the library name and then the file name. I’ve been trying to keep those the same btw so it’s not all wonky like “#include Neo-Pixel/neo_pixel.h”, but it’s bound to start happening. It would be great to abstract the library name away out of the path requirement. That way the library and example files can all have the same include structure for maximum portability. It can make sense when building locally, copying manually into your web IDE app, or included from the Spark Libraries.
Some good questions @BDub
In order to be able to continue to support older versions and vanishing github repos, I'm guessing the library management system keeps a copy of every published version of each library until no applications are using that specific version and a newer version has been published. By doing this, it ensures there's always a local version at hand (in case the github repo is removed), but also cleans up old unused versions.
Dependency-based systems bring many conveniences, but can be fraught with issues - although these are usually not the fault of the dependency system itself but with developer practices (e.g. specifying a range of versions, and not having tested those work.) Initially not supporting ranges is probably a Good Thing (TM).
Yeah, this isn't my favorite naming scheme either, but does help avoid clashes between header files in Say if two libraries have a auxiliary header 'config.h', then this may not work as expected since which config.h get's included comes down to the include path order.
The header/library names should be consistent in most cases since they are produced the shell script that creates the initial library structure. Sure, a library developer could still go out of their way to create different names between the library and the main header, but at least the system has basic tooling in place to steer developers initially in the right direction. If we wanted to be extra strict, the validator could check that there exists a header matching the same name as the library.
Correct. Copies of everything at import time. Commit at import time is also tracked.
Good question. Not sure what the right answer is...I suppose there could be some auto garbage collection type of feature that deletes any library that doesn't have a corresponding repo and that has zero applications that include it. What do you think would make sense?
Yes, I can see that being a bit annoying.
What if we changed the library file naming conventions to so library includers would do #include neopixel/main.h?
Library authors would create firmware/main.h instead of firmware/neopixel.h.