Why another reloader
CrowdHailer opened this issue · comments
Hi,
I was wondering why you made "Yet another reloader". It works great for me and was the first one I came across. Would you consider adding a list of alternatives to the README if this was just an experiment. or consider adding a few lines as to why its better/different to the other elixir reloaders?
I use https://github.com/rustyio/sync when I'm an erlang developer, and I also know reloader from mochiweb and reprise. phoenix_live_reload is requisite if you're a phoenix developer.
I haven't do alternative because I don't think exsync is a good enough project, I don't have unittest and detailed docs for it, maybe I'll do it when I made exsync better.
Further to this question. What are the key things preventing this from being production ready (and eventually release a v1.0).
I am thinking of using exsync as part of a framework for cloud friendly development
exsync is designed for dev environment only, the way exsync used to reload code is :code.purge which may break production system, I think release_handler based library like distillery is a better way for production.
Sorry, I didn't exactly mean ready to use in production. Agreed release handlers the best way to go.
I mean what should be done to get it ready for widespread use, in peoples development environment. A development tool can still reach 1.0 when it is considered stable. So in summary what needs to be done for exsync to be considered stable
Closing this because it isn't actionable.