Particle Library wont upload this library

Firmware Libraries
1

I am trying to get this library to work for a sensor from this repo to upload onto my Particle Photon. I am using the CLI tool to upload the library. In the repo linked, there was no LICENSE file so from the description in the README I added an MIT LICENSE file to get the CLI tool to execute after which I got an error.

The command I use is this:

particle library upload -v

And the output that I receive is this:


Validating library at /home/ljp/dev/tfmini/tfmini-master/
Uploading library TFMini
You are not the owner of this library
Error: You are not the owner of this library
    at Client._throwError (/home/ljp/.particle/node_modules/particle-api-js/lib/Client.js:179:11)
    at /home/ljp/.particle/node_modules/particle-api-js/lib/Client.js:127:12
    at run (/home/ljp/.particle/node_modules/core-js/library/modules/es6.promise.js:75:22)
    at /home/ljp/.particle/node_modules/core-js/library/modules/es6.promise.js:92:30
    at flush (/home/ljp/.particle/node_modules/core-js/library/modules/_microtask.js:18:9)
    at nextTickCallbackWith0Args (node.js:452:9)
    at process._tickCallback (node.js:381:13)

I dug into some of the client side JS and couldn’t figure out how to fix the error. I also tried to go about doing a local build but arm-gcc gave me too many headaches.

2

That error is what's wrong, and won't be affected by local build. There is already a TFMini library uploaded by someone with a different email address, so you cannot upload a library of the same name.

3

When using the WebIDE, I search for the TFMini library and get no results as shown below.
So if there is a library already uploaded how do I go about using it?

Screenshot%20from%202019-01-23%2011-56-10

4

The library is private, which is why you can’t see it. But you still can’t upload another library with the same name.

The best option is to change the name of the library in library.properties and also the .cpp and .h files.

1 Like
5

Thanks! This worked and the library was successfully uploaded.

6

Oof! I can understand not wanting multiple copies of the same library uploaded, when avoidable. But that seems like an annoying little landmine.

1 Like
7

The reasoning behind that was that an original contributor can reserve the name for his library to protect him from getting it snatched away just before publishing.
But it wasn't anticipated that people upload private libraries would hog common names and never publish the libraries.
Now the problem has been realised but a way out of that isn't that trivial to find. A compromise between potentially breaking private code and reclaiming common library names has to be found.

1 Like
8

Yeah, it’s kind of a “damned if you do, damned if you don’t” situation. About the only way out I can think of is if you namespaced the libraries with the username, so “dougal/foolib” and “scruffr/foolib” could live side by side. You’d still have to deal with existing references somehow, though.

1 Like