path to firmware

[jacobrosenthal]

I already have a library live. My source and examples are in the root directory because people download and put in the Arduino libraries dir.

Thus I cant add a firmware subdirectory with my code. How about a location path in the spark.json for non standard paths?

[joegoggins]

Hey @jacobrosenthal , this makes sense. I'm thinking the spec might look like this:

• the default "firmware-root-path" where the libraries .h and .cpp files are located is "firmware" if unspecified.
• users can override it to some other subdirectory within a repo. For "the firmware is in the root of the repo", you'd set the value to "."
• "firmware-test-path" defaults to <firmware-root-path>/test, it can also be overridden.
• "firmware-examples-path" defaults to <firmware-root-path>/examples, it can also be overridden.

So, if you just set firmware-root-path in your spark.json to ., the lib importer would look for examples at examples and tests at test.

[jacobrosenthal]

Deep update is here, and Im back :)
Sounds great to me. This wasn't by any chance implemented yet was it? How do we go forward?

[joegoggins]

😄 thanks for the reminder.

Nope, it has not been implemented yet and we are still hurting for some Ruby gun-power on that side of the house so it might be a minute yet before it gets implemented still.

I had an idea for a ridiculous hack: add a symlink called "firmware" in the local repo dir ala ln -s . firmware to trick the library importer into thinking this dir is there...though I'm not sure this would work.

[jacobrosenthal]

I know rubyists. Is that code open? link?

On Thu, Jul 24, 2014 at 2:44 PM, Joe Goggins notifications@github.com
wrote:

[image: 😄] thanks for the reminder.

Nope, it has not been implemented yet and we are still hurting for some
Ruby gun-power on that side of the house so it might be a minute yet before
it gets implemented still.

I had an idea for a ridiculous hack: add a symlink called "firmware" in
the local repo dir ala ln -s . firmware to trick the library importer
into thinking this dir is there...though I'm not sure this would work.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[jacobrosenthal]

ping?

[blakejakopovic]

I'd like to see support for this as well 👍

@joegoggins Any chance the Spark team can make this a higher priority? Being able to more easily port existing arduino libraries to the Spark would be a huge win.

[towynlin]

Thanks for the suggestions folks. Right now Spark is focused, among other things, on hiring. Reviewing hundreds of applicants takes time. 😉

This issue won't jump to the top of the priority list until we have more front end and full stack developers. If you know good candidates, send them to www.spark.io/jobs

Thanks!

[jacobrosenthal]

To surface the question again, is this code open source and if so can you
link it. I know people or even myself who could just pull request it.

On Thu, Jul 31, 2014 at 6:30 PM, Zachary Crockett notifications@github.com
wrote:

Thanks for the suggestions folks. Right now Spark is focused, among other
things, on hiring. Reviewing hundreds of applicants takes time. [image:
😉]

This issue won't jump to the top of the priority list until we have more
front end and full stack developers. If you know good candidates, send them
to www.spark.io/jobs

Thanks!

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[zsup]

Sorry @jacobrosenthal, this code is not currently open source. I would like to see it become so down the road, but right now it's all tangled in with the rest of our website so it's not easy for us to pull out on its own.

[jacobrosenthal]

Id urge you to keep this issue as high priority as you can. As has been
said, by allowing people to keep their files where they want I can add a
spark.json to all my existing libraries and start pull requesting other
libraries to add a spark.json. Your library support will explode over night.

On Thu, Jul 31, 2014 at 6:47 PM, Zach Supalla notifications@github.com
wrote:

Sorry @jacobrosenthal https://github.com/jacobrosenthal, this code is
not currently open source. I would like to see it become so down the road,
but right now it's all tangled in with the rest of our website so it's not
easy for us to pull out on its own.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[zsup]

Feedback noted, thanks @jacobrosenthal! @joegoggins is on vacation now and this is his part of the stack, so perhaps when he gets back

[joegoggins]

Hey @jacobrosenthal , I agree that this should be high priority because having this capability would dramatically increase the number of libraries. As @towynlin alluded to, we're focussing on hiring and it might not happen for a minute. I appreciate the urging and the patience though.

To @zs- 's point, this code isn't currently open source, but given how it's architected--I don't think it would be too difficult to extract into a RubyGem that we can open source so folks like yourself or others can help us evolve the library system. When we jump into tackling this, we'll shoot to open source this aspect of the site if possible.

[bblanchon]

Is there anything new here?

[joegoggins]

Hey @bblanchon , thanks for the ping.

Though we don't have anything slated for the current Sprint to address this, we have had a bunch of architectural brainstorming sessions speccing out the what the library system should look like in light of the Spark CLI and Spark Dev (which did not exist when the initial library system was built). We will certainly accommodate the changes requested in this issue then.

Additionally, we went ahead and hired a really badass developer, Wojtek, who will likely lead this library system changes effort when it does happen. ( Ping @suda , welcome to this conversation, :) )

[suda]

Hi @bblanchon,

like Joe mentioned, it's not on this sprint, but we definitely will address this issue. Whole libraries system is due for an overhaul, including API endpoints for accessing libraries and supporting them in CLI and Dev. So it's definitely on our roadmap.