Thanks, I try. It’s been great talking with you. I’m glad you’ve put the effort into to understanding the situation.
Ill Chime in my 10p here.
I agree with the OP in that it doesn’t make sense that a community store is not integrated.
Here is how I would do it:
Like the advanced user option, a checkbox with a popup knowing that this comes with no support, warranty, etc.
Community store shows up in the sidebar.
Profit(metaphorically).
I don’t care if its just straight HACS(which would be allowed due to being MIT License) or simply the HACS codebase modified slightly to follow HA DEV Reqs, and I would gladly implement the code for review for this exact option, and submit it to core developers for implementation into “mainline”
That’s all within legal expectations, the question is “would it get allowed” and the answer is very likely no, unless someone on the dev/moderation team would like to tell me otherwise?
The license itself states that it would be fine. So nothing is stopping it from being allowed to be implemented, correct?
If one guy doesn’t want it, but there is obviously a lot of people that want it, isn’t that what open source is about, creating what the community wants?
What are the arguments against building it in?
Other than “the dev who built it doesn’t want it”
(in quotes because I havent seen this, just reading what other people in this thread have stated)
Honest question.
The main developers don’t want in either as I said above. Pretty much everyone (involved with the code) doesn’t want it in core.
um, because it’s a “community store” and not a “built-in store”?
not to mention every other argument against it in this entire thread.
The concept of hacs being difficult to install or some sort of barrier is quite frankly wrong. The install instructions are simple.
If homeassistant required a mandatory Github sign up, I wouldn’t use it.
I agree HACS is not hard to install and in some ways that is part of why I think I have formed an opinion almost the opposite of this WTH.
I am now thinking HA need to make an advanced option that needs to enabled before custom components work. They can be installed but HA won’t load them until the option is enabled. This should have the acceptance/warning notifications required for the user to understand what they are doing, this is currently buried in the logs where the average user will never see it.
As part of the advanced option GUI it would be good to have some specifics about what custom components/files have been loaded into HA.
Maybe eventually this could also be linked back to some threat detection from HA for identified malicious components. I believe these will come if they don’t already exist.
An added benefit to this would be for debugging by being able to disable them all temporarily.
Here as an example of one of the very fundamental problems with this proposal:
HACS isn’t that hard to install. I don’t really see any benefit to integrating it into core personally. The instructions were pretty straightforward. The HACS dev doesn’t think integrating it into core is a good idea. No point brow beating someone who was kind enough to make such an appreciated tool.
That said some HACS integrations are almost defacto mandatory for some installations. For example the core Tuya integration isn’t very reliable for a lot of folks, and the HACS Local Tuya is but can be pretty confusing to configure. In an ideal world the good parts of Local Tuya would be used to make the core Tuya more reliable.
If a dev were looking for inspiration, looking at what’s used most in HACS shows where the user needs and interests aren’t yet covered by core.
In an ideal world no one would buy Tuya devices.
tbh even NodeRed which is offered by HA store requires a counterpart (NodeRed companion) being installed and updated by HACS. Yes, it can be done manually. Who would opt-in for such a pia way?
When I first started using HA and Node-RED, I did not know I “needed” an integration from HACS.
Hi,
Actually installing HACS on a Core (Snap) based system is not so easy to install. I’m having issues with python, which I have posted to the group. So, if it was part of the core system, it would be much easier for me and many others!
I have only a very vague idea of what snap is, but i have no idea why it would be any harder.
Snaps are a strange way of installing software that started on Ubuntu. They basically bundle everything required (all dependencies etc) into a “container” (but not what most of the Linux world would think of … it’s not like not Docker/Podman/etc, more like a Python venv).
Of course, as long as you can find the config folder you can install HACS. Maybe the problem is that @KevinWombat can’t find that?
yeah, python issues would have nothing to do with HACS install because python is not involved with the installation at all wget -O - https://get.hacs.xyz | bash -
Yeah but hacs is python and has aiogithubapi>=22.10.1 as a requirement, and i dunno what that in turn will have as dependencies.
Regardless if snap is different or not that has no bearing as to WHY it’s not in core.
Its not in core because it’s NOT supported by the core dev team. Putting it in core would create false perception. Install mechanism doesn’t matter.
If you need help installing HACS with snap ask the question on your issue installing HACS with snap in a separate thread and let’s leave this one dead. (We made it almost a year, before this got dug up again team… Not bad.)
The owner of HACS has no interest putting this functionality in core. Neither do the developers of Home Assistant. This will not happen, closing the thread.