Package Bash-it with a package manager

[NoahGorny]

I thought about it, and maybe we should start packaging Bash-it in various package managers.
Seems like something that can ease users the need to clone every time and so on.
I am unsure how much work it is, but seems to me like it is something that can be automated with github actions without too much effort.

Notable mention- we currently have a pretty weird way to update- we assume we cloned the project, and we run git fetch and things like that. If we use package managers, we should change our update function to check whether we have cloned the repo or not, and in case we did not, abort and notify the user they should update Bash-it from their package manager.

We also fixed the licensing problem, so with this out of the way, there really is no reason for us not to package Bash-it.
Lemme know what you guys think 😄 @cornfeedhobo @nwinkler @tbhaxor @davidpfarrell @revans @buhl @BarbUk

[buhl]

My main platform at the moment is Ubuntu LTS. It's always waaaay behind official releases, so I would have to continue using a git version to stay current. But it might make sense for other distributions/package managers?

[NoahGorny]

My main platform at the moment is Ubuntu LTS. It's always waaaay behind official releases, so I would have to continue using a git version to stay current. But it might make sense for other distributions/package managers?

You are considered in my opinion a power user, and power users should probably keep using our git, but regular users probably would prefer standard releases, and easier installations, using package managers

[buhl]

It is indeed an interesting idea. I have never made a public package for any distro before and have no idea of what requirements the different package managers have. should be a fun project. 😄
Do you have any idea of how the user base is divided on power-user-level and distro?

[cornfeedhobo]

I see the value and I've packaged a lot of stuff over the years. I can take a look at this some time, but I don't think I'll have free time until the summer. There will likely be a need for small changes, but this seems doable.

[BarbUk]

Nice idea.

I use archlinux and debian for work.
There is already a git package for archlinux.
The pkgbuild script highlights some of the steps to make bash-it as a system package.

I can make a release package that follow https://github.com/Bash-it/bash-it/releases.

There is no package available for debian, it can be interesting to build it for sid.
The package would be compatible with ubuntu.

[buhl]

I don't know if this belongs here or a new issue.
But if packaging is being considered maybe we should also consider following XGD specs having bash-it reside in ${XDG_CONFIG_HOME}/bash-it/?

[cornfeedhobo]

@buhl Not a bad suggestion, but I think we would use XDG_DATA_HOME, and only for power users.

git clone --depth=1 https://github.com/bash-it/bash-it.git "${XDG_DATA_HOME:-$HOME/.local/share}/bash-it"

Of course, this would need changes to install.sh.

However, for a system package, I'd go for somewhere like /usr/share/bash-it.

If you are talking about placing just the config into $XDG_CONFIG_HOME/bash-it, that might be a good pattern to support in both use cases.

[NoahGorny]

Nice idea.

I use archlinux and debian for work.
There is already a git package for archlinux.
The pkgbuild script highlights some of the steps to make bash-it as a system package.

I can make a release package that follow https://github.com/Bash-it/bash-it/releases.

There is no package available for debian, it can be interesting to build it for sid.
The package would be compatible with ubuntu.

Wow @BarbUk, thats pretty cool!
Package managers are a bit of mystery to me
I have never uploaded any package, nor created one. I am thinking about creating an automated process to create one on releases, using github actions, but I have never done so before. I have a few questions:

1. How hard it is to create a package? can it be automated? does making it work for different package managers require a lot of effort?
2. How hard it is to upload it into the official repositories in order for everyone to use it easily? can this process be automated once we get an ACK about creating our package?

I dont want the package creation to be a strain on you/me/anyone here, so I want to make the process as automated as possible, so we could easily distribute the package to our users 😄

Let me know what you think @BarbUk 😃

[cornfeedhobo]

@NoahGorny I'd like to push that we use as agnostic a system as possible. I've used many build systems and abstractions over the years. I think for our use case, we're best off using fpm. As for getting the resulting artifacts into upstream repos, each distro has a different process and we'll need to figure that out.

I wish I had more time right now, but this is a low priority for me.

[cornfeedhobo]

First thing I want tested and answered:
When putting bash-it in a shared location (/usr/share/bash-it) how should it be expected to load components?

I think the way bash-it loads files will be a problem. In a lot of places we use relative loads, but this will require absolute, and the place activated components are loaded from will differ from $BASH_IT, which will need handling.

Presumably, each user will want their own configuration, so maybe we'll need an install command that each user can use to setup their environment, or at the very least print documentation on how to do it themselves.

I'm sure there are more questions I'm not thinking of, but the way I would go about discovering them is placing the code in /usr/share/bash-it and seeing what changes need to be made to get things working with a test user. That's what I'll be doing if I can get to this soon.

[nwinkler]

Yes, that's true:

• The Bash-it files would need to be in the shared location (/usr/share/bash-it), and
• The enabled directory would need to be in the user's home.

Any Bash-it code that works on the enabled directory (read/write) would need to be adjusted. That's primarily the lib/helpers.bash and scripts/reloader.bash files, potentially a couple more. We have decent test coverage for those two, so making changes there should be feasible.

In my Bash-it fork, the bash_it.sh file defines the BASH_IT_CONFIG variable, based on XDG_CONFIG_HOME, that looks like a candidate for putting the enabled folder in:

https://github.com/nwinkler/bash-it/blob/8cc7f6c388260f3b178acf2baf58cb8eb1edd416/bash_it.sh#L14

I use this location for storing some config values related to the proxy plugin.