You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the homebrew style install (using symlinks) from bin to internal files breaks lit's updater. It will think the lit internal folder is the main bin and install a copy of luvit and luvi there where they are not in the user's path. The public luvit and luvi symlinks will still be linked to the old versions and it will look like the update failed.
We could be clever and read the symlinks and update the target binaries in-place. Also we could replace the symlinks with normal bianries. Both of these methods break assumptions that homebrew makes. We could just refuse to update in this case and tell them to update via homebrew (hoping they can keep up with our rapid release schedule)
The text was updated successfully, but these errors were encountered:
Yes, the solution will be to detect a homebrew install and disable update in that case. We'll print a nice message to the user that they need to update via the homebrew system instead since that is how they initially installed luvit and lit.
Currently the homebrew style install (using symlinks) from bin to internal files breaks lit's updater. It will think the lit internal folder is the main bin and install a copy of luvit and luvi there where they are not in the user's path. The public luvit and luvi symlinks will still be linked to the old versions and it will look like the update failed.
We could be clever and read the symlinks and update the target binaries in-place. Also we could replace the symlinks with normal bianries. Both of these methods break assumptions that homebrew makes. We could just refuse to update in this case and tell them to update via homebrew (hoping they can keep up with our rapid release schedule)
The text was updated successfully, but these errors were encountered: