hacsfiles isn’t a directory. It’s a keyword that links to a directory path. Take a second and open your /config/www directory and tell me what directories you see.
/local isn’t a directory. It’s a keyword that links to a directory path.
You can use either. One is a map (/local). The other is the actual directory (/config/www).
I don’t know how else to describe this to you. It’s really not a hard concept. It’s like a variable.
You don’t need to describe basics. I’m a developer too.
I’m just wondering why:
people got confused by /local vs /config/www. maybe the confusion was originating from unconsistent documentation? Why just not simply get rid of confusion and use one path in communication with users (ie /config/www). I would touch this subject, but it’s you who mentioned the confusion as a reason wy HACS added own mapping
why HACS must have created another mapping (I can see it’s hacsfiles/ being mapped to /config/www/community/). The non-persistant mapping btw. Why just no allow to chose a location the user wants to use. Or why not store those files somewhere in physical directories (ie in /share directory) and create softlink in www space)
In general I wouldn’t care, but as pointed at the beginning of this discussion, once HACS dies, those files are not served anymore because URL points to unexistent path. Now I know I can change path to resources on my own, but by default HACS sets those paths to hacsfiles/ while I’m not aware this path can be configurable.
mapping is never persistent. It seems persistent but that’s only because HA creates it every startup.
That would be a support nightmare, more than /config/www → /local.
what’s the point? That’s no different than what we already have. It’s just a different location.
The directions in hacs only uses hacsfiles because URLS are too complicated for people. Yes. You read that correctly. It was too complicated for people to browse to the location of their files and change the URL in resources to match that location. It originally worked this way and was changed to /hacsfiles so that people could just copy and paste the URL or so that HACS could do it for you.
But right now HACS does all this work fon its own: it copies files into location and adds it to HA resources. So AFAIK problem with people who found things too complicated has been solved this way.
Additing features is great. but adding them for price of reliability doesn’t seem to be good approach. especialy in HA systems which by design should be considered mission critical. Systems shouldb’t break apart just because one component fails. Especially in such trivial case like hosting js files.
That’s why I mentioned soft links. Wouldn’t soft link privide the same functionality making system working even without HACS running at the same time?
I may agree or not with current approach, but at least now I know the motivation behind those decisions. Thank you for your time.
BTW ifrom HACS changelog: The next planned version (1.9.0) will have HA 1.0.0 as the minimum required version.
I bumped into a similar situation, but was already at the latest version. I downgraded, so that I could upgrade and then I was able to reinstall HACS. Thanks for posting this as I never would have thought to try it.