HACS disapeared, cannot remove it, cannot add it again

[petro]

@maxym

So, when hacs is starting it adds mapping to hacsfiles directory which exists until next restart?

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.

@maxym

Why forget about local and use config/www only?

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.

X = 4

You can use 4 or X and they both represent 4.

so in this case…

/local = /config/www

[maxym]

You don’t need to describe basics. I’m a developer too.

I’m just wondering why:

1. 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
2. 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.

[petro]

@maxym

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

It’s for hosting files.

HTTP

@maxym

why HACS must have created another mapping (I can see it’s hacsfiles/ being mapped to /config/www/community/). The non-persistant mapping btw.

mapping is never persistent. It seems persistent but that’s only because HA creates it every startup.

@maxym

Why just no allow to chose a location the user wants to use.

That would be a support nightmare, more than /config/www → /local.

@maxym

Or why not store those files somewhere in physical directories (ie in /share directory) and create softlink in www space)

what’s the point? That’s no different than what we already have. It’s just a different location.

@maxym

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.

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.

[maxym]

@petro

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.

@petro

mapping is never persistent

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.

[KTibow (Kendell R)]

Note that /hacsfiles/whatever removes caching, so you get instant file updates as soon as you update in HACS and refresh.

[athaynes (Adam Haynes)]

@maxym

In an act of desperation I decided to do one more thing before installing HA from scretch: I updated HA to most recent version (from 0.117.6 to 0.118.5).

After that I attempted to add HACS which this time finished with success!

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.