The new .atuin directory

Feedback
1

I have just made some questions in a reply in another topic, but I thought it best to create a topic.

It seems to me that the directory at ~/.atuin is a recent change (latest release?) that is not well documented (or at all?). Could you please comment on that?

In relation to that, I wanted to express my opinion that this is less that optimal for the following reasons:

  • I now have the latest atuin executable in $HOME/.atuin/bin/, but I am also left with another atuin executable in /usr/bin/atuin.
  • I would rather atuin used standard bin directories instead of creating yet another on in the home directory. Is there a particular reason it does not place its binary in $HOME/.local/bin ?

Looking forward to hear your thoughts! In any case, let me say a big thank you for your work, atuin is amazing :slight_smile:

2

Hey!

The installer will have told you what it’s doing, for example:

downloading atuin 18.3.0 aarch64-apple-darwin
installing to /Users/ellie/.atuin/bin
  atuin
  atuin-update
everything's installed!

We tried for a really long time to try and use the system package manager exclusively, but due to the amount of questions like in the other thread you commented on, we’re shifting to our own installer. It includes atuin-update, which updates to the latest release without needing to run the installer again.

That way, if users choose to use their package manager then they know what to do, and if not then we can help them.

Our install script has always said what it’s doing, but I don’t think people read the output. Right now the install script falls back to our own binary install if it cannot use a package manager, and in the next release will always be the way. Previously we’d compile from source, but now we download a binary.

I appreciate this, however it was discussed in the prerelease notes for 18.3.0, and also the release notes for 18.3.0. I just added something else to the docs, but you have any suggestions to make them more clear, I’d really appreciate a PR!

Thanks! Glad you like it :smiley:

3

Thanks for the quick reply! :green_heart:

Our install script has always said what it’s doing, but I don’t think people read the output.

Indeed, as I mentioned I was maybe wrong and had missed some standard output somewhere, even though I do try to read it.

Please only take my comments as constructive criticism and feedback from a user, as I said, I love Atuin.

I am not sure how it would be best to change the docs (and you said you have already made some change so maybe that already covers it), but for example searching for atuin-update in the docs search bar does not return a relevant result. Nor does the same search in the blog (although that was anyway not the first place I would have thought to search in).

I appreciate and understand the reasons for changing the release workflow, I still am not sure why it had to be installed in a new location and not in a standard bin directory, namely $HOME/.local/bin.

I am also touching again upon the change to the user’s .zshenv (in order to source the new env file). The reasons why I am not keen on this kind of change is that:

  1. I, like many, use some kind of dotfile manager (in my case chezmoi), so if I miss that a change was made to the actual “destination” file, I may easily overwrite the change with the repository version of that dotfile. That may be a particular problem with how chezmoi does things, and I am sure each dotfile manager has its own quirks. That is precisely why I think notifying the user that they should modify their dotfile is preferable to doing it automatically for them.

  2. This is even more personal, but in my case my ~/.zshenv file is only there to actually modify the ZDOTDIR variable to $HOME/.config/zsh. I do this as I prefer to keep all configs in the standard XDG_CONFIG_HOME. This is another reason I would rather atuin had told me to add . $HOME/.atuin/bin/env to my .zshenv (wherever it might be), instead of doing it automatically.

As I said, I am just sharing user experience feedback, hoping that it can be useful, but it is in no way hard criticism.

Take care :v:

1 Like
4

Thanks for the feedback! :pray: Tbh, it sounds like the fully automated install script is targetting a user that is not you.

Generally I’m trying to make it easier to help and support users that wish to easily work with Atuin, find all the files releated to it, etc. This way, everything related to Atuin can be in one spot, rather than spread across several directories. Cleaning up if you decide you don’t want it is much simpler this way, backing up all Atuin data is easier, etc.

There’s a big divide in users - those that wish to have everything configured in precisely the way they want - perhaps following some freedesktop specs exactly, and those that just want it to work quickly and aren’t fussed.

The fully automated install is targetting the latter group, and the manual/configurable install the former.

For example, before the install script edited .zshrc automatically, I spent heaps of time telling people that they needed to set it up - even though it was in the docs, in several places. I still spend a lot of time telling people that the install script will try to use the package manager, will try to follow specs, etc, so I cannot give a definitive answer as to where things are. Going forwards, the fully automated install script will always do one thing, on every system, and precisely document this. We’re not quite there yet, but will be soon.

If you don’t like that, you can follow the manual steps and get it setup in a way you + your environment are happy with! Generally people that take these steps need much less support.

I think even before this change the script would have caused issues for you, as it edited your .zshrc file automatically too.

Otherwise, specifically about .local/bin. The XDG spec is generally very vague, and inconsistent. It provides env vars for directories such as XDG_DATA_HOME, XDG_STATE_HOME, etc, but it does not provide XDG_BIN_HOME. I’d be more open to supporting it if it did

Progress on this front has stalled: [PATCH] document ~/.local/bin (#14) · Issues · xdg / xdg-specs · GitLab

And actually not the first time the XDG spec has been frustrating - see XDG_STATE_HOME for the location of history data

In general, it’s unclear if users wish us to follow spec to the letter, follow convention, or something else. Hence for the time being, the decision can be left to the user.

We could support XDG_BIN_HOME regardless of what the spec says, or perhaps just ATUIN_BIN_DIR.

1 Like
5

Thanks for taking the extra time to give your insight on this, I really appreciate it and I understand your point of view.

1 Like
6

No problem! Thanks for the discussion :blush: Hope atuin continues to work well for you

7

should we delete the old /usr/bin/atuin?

I fear touching it for lest it break something…

BTW, I agree on the use of ~/.local/bin to store things, but I’ve also seen many other project doing exactly as @ellie has done with the ~/.foo … it seems the whole FHS is fracturing

8

I’d be happy with making the installer accept a var for where to put the binary, but honestly by default I’d rather keep it as simple as we can.

I really wish XDG would accept XDG_BIN_DIR :joy:

1 Like
9

XDG_BIN_HOME is close, but curse them for not including it in the spec.

A thing I’ve noticed, is that Steam puts its executables into XDG_DATA_HOME.

10

I think while some people may like this, many others will not. Until there’s actually a well defined and widely followed spec, I’d rather have two options for users

  1. Fast easy install, easy to support, minimal decisions to make
  2. Fully customizable, put things wherever you want, more decisions to make