Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packaging dotbare (for the AUR) #15

Open
wallace11 opened this issue Jul 3, 2020 · 6 comments
Open

Packaging dotbare (for the AUR) #15

wallace11 opened this issue Jul 3, 2020 · 6 comments

Comments

@wallace11
Copy link

wallace11 commented Jul 3, 2020

Hi,
I hope you don't mind that I went ahead and packaged dotbare in the AUR.
I wanted to take this opportunity to discuss ways to improve availability on different systems, since your choice of offering dotbare as a shell extension makes it quite a challenge for distro packagers.
Taking a look at the source code, I noticed the shell extension file simply adds dotbare main file to the shell, which is equivalent of having it in $PATH. I also noticed you mentioned it as an option for installation. However, where the project currently stands, it's impossible to have the main file inside $PATH without scripts and helper directories, so I had to create a custom wrapper to do that and completely ditch shell extension for the AUR package.

Hope you'd consider making this project more packaging friendly, so it's possible to make it available on different systems more easily ;)

Keep up your great work!

@BachoSeven
Copy link

Hi there, I was going to write you a comment in the AUR, but I suppose here wil do: first of all I support the packaging effort as it is much better for integrating dotbare in my bootstrapping scripts; secondly with regards to the AUR package, it seems you have linked a completey different upstream link, you might want to fix that.

@wallace11
Copy link
Author

  1. It's great to see that you're willing to better support packaging. Please feel free to ask for advice if you need one.
  2. Such an embarrassing mistake with project page. Fixed right away.

@kazhala
Copy link
Owner

kazhala commented Jul 3, 2020

Hi, thanks for the effort of packaging dotbare. I have nothing against it, as this was originally one of the plans during the first release, I moved to the shell plugin direction due to it's the easiest and thanks to @NICHOLAS85 was kind enough to make a zsh plugin file to use for zsh plugins to get things started.

I'm not planning to introduce code structure changes such as moving all code to one file like bashtop. With that said, I had a look at the AUR link and saw that you are using install as of now. Instead of using install during the package installation, is it possible to use ln to create a symlink points to dotbare executable? During my research at the first release, I know that I could use readlink to resolve the symlink in dotbare main file but I haven't tried to implement yet (reference).

With regarding dotbare.plugin.zsh and dotbare.plugin.bash, they are planned to also include cmd completion definition for both git commands and dotbare commands in the near future (bash plugin already implemented the completion for dotbare) so it will server more purpose than just adding it to the PATH. Since the plugin file might also get sourced for completion of packaging installation, I might have to somehow detect it and prevent the plugin file to add PATH (assuming the package installation is probably symlinking dotbare executable?).

@wallace11
Copy link
Author

Hey,
I replied to the other comment via my email and thought it was the maintainer. Hope you didn't get offended ;)

  1. Regarding linking: I'll have to check if that's not against the best practices of packaging, since I've never seen anyone doing that and Arch users are very strict about them. As you mentioned, dotbare doesn't support symlinking its main file as of now, so maybe as part of a fix to this, we may be able to find a way to have it on a different location (namely /usr/bin) and the other files in /usr/share/dotbare.
  2. Regarding plugins: completion is a completely different story (pun intended). Provided it doesn't mess up other things because of sourcing (like you mentioned), I don't see why can't we include them in the package as well.

@BachoSeven
Copy link

BachoSeven commented Jul 4, 2020

For git completion, I just have the following lines in a _dotbare file which i added to fpath in .zshrc:

#compdef dotbare

compdef dotbare=git

So for manual installation this instructions could be added to the Readme; as for the AUR package you could just add such file to /usr/share/zsh/functions/Completion/Unix, since that is where most programs put it (i.e. git). And of course you could add dotbare-specific completion to it.

@kazhala
Copy link
Owner

kazhala commented Jul 4, 2020

Thanks for the tips @BachoSeven. I'll take consideration of making a dedicated completion file, as of now, at least the first round of completion development, I'm planning and already started to provide completion definition into the dotbare.plugin.bash and dotbare.plugin.zsh file.

Two reasons I made this choice:

  1. zsh plugin or bash user will have a simple way to get completion as just invoking a function (highest priority)
  2. Haven't started the zsh completion yet, but for bash, at least for now it's not easy to provide both dotbare completion and git completion, there will be seperate completion function defined and hence the user will have a choice which function to invoke to get which completion

Which I guess it could still get sourced even for package installation (just that I will need to do more checks not to add duplicate PATH). Alternatively, I could organise completion into dedicated completion files and then source those in dotbare.plugin.bash and dotbare.plugin.zsh appropriate functions (I guess this is probably a better way for the package installation)

I'm planning to have a dedicated completion section in README to explain how to set it up for different installation method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants