Replies: 8 comments 4 replies
-
|
It does sound cool. Would be interested to know how other people feel about this. One immediate problem I see is what happens if you use Also, if we ever want to make changes to the update mechanism, it must be compatible with the old typst self-updater. A separate tool would suffer less from this issue because you can have a recent version of it and still use it to install an old compiler version. That said, I agree that having it built in is cooler. Third, I wonder how this integrates with installations from package managers. Presumably, it is not desired that a binary that is managed by the package manager just modifies itself. |
Beta Was this translation helpful? Give feedback.
-
|
Per my comment on the related PR, this should not be enabled by default and should be behind a feature flag that distro packagers could disable. Having a binary that tries to replace itself or anything else placed by the package manager is a good way to totally mess up a system and should not be a feature enabled at all in anything built and installed by a package manager. All self-updating software runs into this issue and projects that don't support a feature flag to disable it often require distro packagers to add their own patches to remove the potentially breaking functions. |
Beta Was this translation helpful? Give feedback.
-
|
I think if you downgrade to a version that does not support As to package managers, if you use those, then you can upgrade using them, and the binary would live in |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback, appreciate the quick response.
When downgrading to an older version a We could also opt for @pepa65's idea, the update functionality would simply disappear from your current install if it doesn't have support for it, but that could leave someone scratching their head when they made a mistake and would like to revert but can't anymore.
The self-updater should then always be backwards compatible but I'm not sure if that is a good idea and if we would even want that. Running
I personally don't use one, hence why I wanted to introduce it into the binary itself. An argument can be made that everyone should use an external package manager if they want this functionality, but I still feel it would be a nice addition for people that don't use a package manager to get the typst binary. I would have no idea what would happen if you update it through the self-updater and then try to update it through a package manager though, I would assume it should all work fine. Further testing might be needed. |
Beta Was this translation helpful? Give feedback.
-
|
My normal repos don't have |
Beta Was this translation helpful? Give feedback.
-
|
For distributions of typst installed via a package manager, this feature should no be included so there should be a compile option to completely disable it. I personally do not like the idea of applications (esp. CLI ones) that come with their own update mechanism. For a LTR distro you could create/add some repo that distributes typst and add that to your package manager? |
Beta Was this translation helpful? Give feedback.
-
|
What would be a downside from having both the option to update it through a package manager and having the binary update and replace itself? If you don't use a package manager your only option is to download a precompiled binary from the Typst repository, which can become quite cumbersome when you update frequently. |
Beta Was this translation helpful? Give feedback.
-
|
A valuable argument to consider against this feature would be that package managers tend to install their packages into directories that users cannot write to without root privileges. If that somehow does work they might silently break the install in some way where a package manager might not be able to recover from it. (summarized from tinger on Discord) I have no experience with combining self updating binaries and package managers and what that would exactly entail, so I would need to do further testing or I would gladly see a comment from someone that has more experience with this. |
Beta Was this translation helpful? Give feedback.
-
|
When software gets packaged in a distro, they (usually) compile it against their stack. A @johannes-wolf said, they would just not compile the |
Beta Was this translation helpful? Give feedback.
-
|
This sounds similar to what @alerque said #1848 (reply in thread), hiding this feature behind an feature flag and disabling it by default would work when package managers compile it. Would it be okay to enable it for all pre-compiled binaries that are added to releases? |
Beta Was this translation helpful? Give feedback.
-
|
I've seen multiple people express that this would be a good feature to have for the more "casual" windows users that don't like/can use a package manager. I'm going to give implementing this a shot and see if I can come up with a prototype that we can iterate on. One thing to note is that I previously mentioned that I was going to use |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
I wanted to let the typst binary update itself in-place through a CLI command:
typst update, aiming for similar behavior likerustup update.Instead of grabbing the latest (or a specific) precompiled binary from the GitHub releases I would like to be able to run something like
typst updateortypst update 0.6.0and have the binary update itself by getting the version specified and install it in the same place and have it replace itself. Runningtypst updatewould give you the latest available binary. If updating to latest would come with too many breaking changes maybe atypst update revertwould be in order to get the user back into a workable state by simply putting back the binary the user was updating from.I wanted to open a discussion first to see if there was any interest in this feature and how it ought to be built.
I do want to add that if this feature gets approved I would love to take a shot at implementing it. I already have some ideas on how I want to implement the feature; off the top of my head I would introduce two dependencies:
octocrab, a GitHub API client.self-replace, allows for binary self replacement.The
Commandswould get a new sub command variant calledUpdate.I'd love to hear some feedback on this!
Beta Was this translation helpful? Give feedback.
All reactions