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?

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

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?

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.

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.

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/?

@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.

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 😃

@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.

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.

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.

I feel like this issue is a major thing we should focus on, as this will have great value to our users and community. This is however quite complicated:

• we need to refactor many places which touch the enabled directory (apart from the tests, which are not interesting, there are not too many places).
• bash-it update would need to be adjusted, as it needs to be disabled on system installs.
• we need to actually try to package bash-it, and see if we can use it and publish it

I tried to take a look at that, but got quite confused. I do not want to do more harm than good, so I am marking this as help-wanted. If anyone wants to try and take this on- you will have our support ❤️

Some brainstorming from a comment I just left in #1865:

the whole symlinks thing will need to be replaced

If we like the bash-it enable plugin base paradigm, then "profiles" might be the perfect way to do it. Hypothetical: The user's current, live "profile" is custom.profile in (e.g.), ~/.config/bash_it/profiles, and importing an external profile (e.g., "snazzIt") either replaces or adds to it. Or, copy the snazzIt profile in to the profiles folder and now the user has two profiles: custom and snazzIt and can switch between them. Then, the first time the user changes something copy snazzIt to snazzIt.custom before modifying it.

Of course, this would mean that profiles aren't so much imported as just parsed by reloader.bash during startup.

Hi, It's been a while since I have been here. I have been a little unfaithful and have been flirting with nixos and home-manager which atm doesn't have a package for bash-it.
I have reached a (probably imagined) level of confidence to try to create a package for bash-it. I think the nix way would be to not allow bash-it en/dis-able to work and everything to be configured at install time. I have a working private copy of this right now.
However i have also created a bash-it fork which supports having the folders custom and enabled outside the source directory
https://github.com/buhl/bash-it/tree/feature/config_home
I have not tested it thoroughly yet. In fact the tests might fail since I haven't touched them yet. I this something the project would like me to work some more on or is the solution I have chosen not in line with the future path?
Simply explained I have created a BASH_IT_CONFIG env which can be BASH_IT or what ever other valid path a user would like.

Hi, It's been a while since I have been here. I have been a little unfaithful and have been flirting with nixos and home-manager which atm doesn't have a package for bash-it. I have reached a (probably imagined) level of confidence to try to create a package for bash-it. I think the nix way would be to not allow bash-it en/dis-able to work and everything to be configured at install time. I have a working private copy of this right now. However i have also created a bash-it fork which supports having the folders custom and enabled outside the source directory https://github.com/buhl/bash-it/tree/feature/config_home I have not tested it thoroughly yet. In fact the tests might fail since I haven't touched them yet. I this something the project would like me to work some more on or is the solution I have chosen not in line with the future path? Simply explained I have created a BASH_IT_CONFIG env which can be BASH_IT or what ever other valid path a user would like.

Hi @buhl, glad to have you back 😄
We indeed want to split the writable configuration from the non writable code. Your solution seems to be in line with this vision. Let's try to create a PR with some testing so we can take a closer look 😃

hello guys!
any update on this?

Bashit v3.0.3 is now available for Arch Linux users from AUR. https://aur.archlinux.org/packages/bash-it

Bashit v3.0.3 is now available for Arch Linux users from AUR. https://aur.archlinux.org/packages/bash-it

We should mention this on the README as we go mainstream 😄 Still waiting for deb package.