For a long time I wanted to try and prioritise using package managers, so we would have the smallest impact on the users machine possible. Unfortunately with this change, the install script will no longer be doing this.
Firstly, we're limited by which package managers we are in. The fallback to build from source really sucks on systems like a raspberry pi (running a flavour of debian). For that specific case, it's worth noting that Debian's repositories are very stable - even if we were packaged there, Atuin would rapidly become so out of date that it would no longer sync. Hence the proliferation of ppas.
Increasing the breadth of package managers we are included in becomes tricky in terms of support. Some have much stricter requirements than others, including dynamic linking as much as possible or high levels of patching - both make supporting users and replicating their issues harder, and is not something we can support. We've already seen a couple of issues that will only occur when using the system sqlite, vs the pinned, tested, and bundled version we build.
Secondly (the primary issue), it's diffcult to tell users precisely what the script has done. The "it depends on your system and package manager" has been met with frustrated responses, and I really want to streamline things there.
The cargo-dist installer provides a consistent install location, consistent binary, consistent update path, and is much easier for us to support.
I am very aware that some users may have issues with ~/.atuin being used. Really, the automatic installer is not for them. The idea with this installer is to streamline installs as much as possible for users that just wish to have things working quickly, and to make it easier for us to support them. There's more discussion about this on the forum post
If you're someone who prefers to have your setup just how you like it, we provide a whole bunch of alternate install methods that will work well for you! You can probably just go ahead and use your package manager (and then setup the shell plugin!)
Checks
[ ] I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
[ ] I have checked that there are no existing pull requests for the same thing
For a long time I wanted to try and prioritise using package managers, so we would have the smallest impact on the users machine possible. Unfortunately with this change, the install script will no longer be doing this.
Firstly, we're limited by which package managers we are in. The fallback to build from source really sucks on systems like a raspberry pi (running a flavour of debian). For that specific case, it's worth noting that Debian's repositories are very stable - even if we were packaged there, Atuin would rapidly become so out of date that it would no longer sync. Hence the proliferation of ppas.
Increasing the breadth of package managers we are included in becomes tricky in terms of support. Some have much stricter requirements than others, including dynamic linking as much as possible or high levels of patching - both make supporting users and replicating their issues harder, and is not something we can support. We've already seen a couple of issues that will only occur when using the system sqlite, vs the pinned, tested, and bundled version we build.
Secondly (the primary issue), it's diffcult to tell users precisely what the script has done. The "it depends on your system and package manager" has been met with frustrated responses, and I really want to streamline things there.
The cargo-dist installer provides a consistent install location, consistent binary, consistent update path, and is much easier for us to support.
I am very aware that some users may have issues with ~/.atuin being used. Really, the automatic installer is not for them. The idea with this installer is to streamline installs as much as possible for users that just wish to have things working quickly, and to make it easier for us to support them. There's more discussion about this on the forum post
If you're someone who prefers to have your setup just how you like it, we provide a whole bunch of alternate install methods that will work well for you! You can probably just go ahead and use your package manager (and then setup the shell plugin!)
Checks