How to use library code

Any documentation? None found in supplied link.

@gopher.ny

This is needed:

library (
    base: "driver",
    author: "johnlcox",
    category: "driverUtilities",
    description: "driverUtilities",
    name: "driverUtilities",
    namespace: "python",
    documentationLink: ""
)
1 Like

I'll write something up, but here are some examples in the meantime. First, define a library with variables, methods, etc. just as they would appear in app/driver:

library (
  author: "gopher.ny",
  category: "samples",
  description: "Some description",
  name: "sampleTwo",
  namespace: "samples",
  documentationLink: "http://www.google.com/"
)

void method1() {}

Then, include library anywhere in the code with #include statement, starting at the beginning of the line (no spaces before #):

#include samples.sampleTwo

That's it, include will be substituted when app/driver/library is saved. All apps/drivers using include are recompiled when include gets a change. You can click on the download icon next to Import button to see exactly how the include gets into the source code.
image

Edit: #include's parameters (if one can call them that) is namespace, followed by a dot, followed by name. Names and namespaces can include letters (upper/lower case), numbers, dots, dashes, and underscores.

3 Likes

What does this entry from @Bago's example represent? And do category, description, or documentationLink get used anywhere in the interface?

base option no longer means anything and is ignored.

Not at this time, but they will be at some point. Required attributes are namespace, name, description, and author.

2 Likes

Each driver uses the same version of a library. You put common code in the library, and driver specific code in the driver itself.

1 Like

If "three different versions of the same library" is technically achieved with "three different libraries", it should work.

I'd say just add a version number suffix to library name.
Amazon is doing it, and extra numbers are free of charge...

5 Likes

The idea for a publicly published library would be that it shouldn't change. This is not a solution for version management, only for code inclusion.

4 Likes

I would add that it could be expected to change by being extended, but the existing methods should ideally stay the same (or at least remain interface and functionally compatible) over time.

1 Like

I think the way I would handle it would be to do a v2, etc for major breaking changes. For the most part if you keep the same core code and functions you should be able to update without breaking anything drastic, especially if it is used mainly for your own drivers as they can be adapted at the same time. If you add features, that should not break anything that uses existing features. These would be minor version updates.

If you do a total overhaul thats going to break backwards compatibility then do 'libraryname2' so anyone else using the original can migrate to the new one at their leisure.

I think this is what you are referencing as being a problem, but if it is managed correctly with thought put into it, to limit major version changes then I don't see why it would be an issue.

Libraries are a way to reuse the code, an alternative to copy/pasting code in multiple apps/drivers. It's really just that, a very basic feature, but we found it very useful internally from code maintenance perspective and decided to share it.

7 Likes

This isn't a facility that we have at this time. The subject of code management for developers who want to publish apps and drivers is beyond the scope of what we have done. So, don't read more into Libraries than is there.

I think it is always up to someone re-using a library to rename/rev it up - or use it as-is and expect the original author to make changes.

If someone wanted to still use the library as-is in your example, they would just go change global: "false" to "true" anyway, wouldn't they?

So you can't really stop people from incorrectly using library code...

1 Like

Well, some people better be prepared to be disappointed then. :slight_smile:

6 Likes

That's not how things work in the real world. If it were, it wouldn't be necessary for us to spend weeks doing regression testing of our code when publicly available code changes. Most developers intend to keep as much backward compatibility as possible. Sometimes it just can't be done, because of other libraries, applications, etc. that have changed and cannot provide backward compatibility for good reason.

Every developer is trying to move the functionality and usability of their code forward, and they are generally doing that without any discussion with those whose code they depend on. this is the developer's life. Take the red pill work with it like you do at work, otherwise if you take the blue pill you'd

Anyone know how this.is going to affect hpm. Seems to me.for now will be broken when using libraries.

Only one person to ask about that... @dman2306 :eyes:

1 Like

Yup. I'll be honest, I haven't given this a ton of thought at this point. I've been pretty focused on just trying to get my hub into a working state. I haven't even really played with libraries much at all yet at this point.

This is the main reason I haven't given it much thought yet. I feel like this is a pretty big problem. I've kind of toyed with the idea of if I implement this in HPM, should I implement an automated namespace mangling feature so that we don't have to worry about this? When HPM "hides" from the user the fact that it's installing stared libraries that may or may not stomp on each other, I feel like HPM winds up owning some responsibility since the user is no longer making the action him/herself.

2 Likes

Or HPM cannot have any packages that use libraries. To avoid conflicts. :stuck_out_tongue_winking_eye:

4 Likes

Download the Hubitat app