I can't speak for Dominick exactly, but there was a lengthy discussion about this in Beta testing that he participated in.
There are some challenges to overcome with the use of these new libraries and bundles, and it may or may not make sense to support them. They are so new I am not sure if anyone has really explored the use of them that deeply. Or if it even makes sense to use them at all.
Either way, I wouldn't expect anything anytime to show up in HPM in the near future from my observation of how that discussion went.
I think that this is a discussion that someone (you?) should start as a new thread. I am not a coder, so I don't understand why exactly these would be "convenient". (Don't even bother explaining to me ) I guess I get the reusing code part to a point, but there seem to be some pitfalls with this code reuse, at least with this early version of libraries.
Maybe a bunch of people smarter than me can hash out the use case for these, and how they should be implemented as well as any feature that need to be added. That thread in Beta was pretty interesting, but it isn't visible to everyone, so a new thread probably would be appropriate.
I plan to add library support but I don’t really feel like bundles fit in HPM. What exactly would you be looking to do with a bundle that you can’t already do in HPM?
Bundles appear to deal with the needs for different ordering for install vs. update (which can affect parent/child apps and apps/drivers).
It may offer HPM less steps as far as downloading components.
It likely would be a good optional add to HPM, but likely given the different HE firmware versions in the world, HPM would have to deal with both styles of deployment...
HPM already handles the install ordering. Also HPM would not be able to read the contents of a bundle since there is no way to read a zip file from an app. I don’t really see the value. It’s a lot of extra work to code too. So I don’t have plans to add it. Libraries on the other hand make sense. I’m just sorting out the details and I’ve been busy the last couple weeks.
My use case is for my LIFX Drivers which have one app - probably soon to be two, and seven drivers (soon to be eight), and will have one or more libraries once I get round to it.
I don't have a particular need for bundles, although I'll probably create one in addition to the HPM support to make it easier for people who don't use HPM.
Hi there, new to HE, migrating from Vera, getting this error when adding HE pkg manager- java.lang.NullPointerException: Cannot get property 'repositories' on null object on line 3546 (method prefSettings)
The libraries make sense, it's just finding time to code it that's been the challenge. It'll definitely happen soon though. Bundles, however, I just don't see adding much value to HPM because HPM already does everything a bundle can do. In fact, they would restrict what HPM can do! For example what you mentioned -- 8 drivers, you only make changes to one. Well if everything is in a zip file (bundle) youy have to download the whole zip instead of just the single groovy file for that one driver. Using separate files might cause a little more HTTP traffic on first install, but it lets us have specific/selective updates.
I don't understand what you're saying here. Why is it "generally a bad idea"? It hasn't caused any issues that I'm aware of. Can you provide an example of why this is a problem?
I agree that bundles don't make sense for HPM. For manual installs they make a lot of sense for my use case (and even more so once I start including libraries), but I'd still rather people used HPM since it's so much more convenient.
Sorry, this premise doesn’t make sense to me. I still don’t understand what problem this is solving. What does the current method employed by HPM break? If you’re suggesting that for the brief second during the upgrade you might get an error because, say, a method has been renamed. Sure, but that can go in either direction and then in my opinion, that is on the package author to write backwards compatible code.
I’ve yet to experience any of these problems. This feels like an extreme corner case to me. I also don’t think install order solves it, you need simultaneous install. Parents can depend on children and vice versa. When the dependency can exist in either direction, order will not solve it. As a note I have written a ton of complex parent/child apps and experience no issues. I still see you talking in theory. I’d love an actual example of something that is broken.
) I guess I get the reusing code part to a point, but there seem to be some pitfalls with this code reuse, at least with this early version of libraries.
