Package Bash-it with a package manager

NoahGorny commented 3 years ago

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 :smile: @cornfeedhobo @nwinkler @tbhaxor @davidpfarrell @revans @buhl @BarbUk

buhl commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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. :smile: Do you have any idea of how the user base is divided on power-user-level and distro?

cornfeedhobo commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 :smile:

Let me know what you think @BarbUk :smiley:

cornfeedhobo commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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.

NoahGorny commented 3 years ago

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 :heart:

gaelicWizard commented 3 years ago

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.

buhl commented 2 years ago

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.

NoahGorny commented 2 years ago

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 :smile: 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 :smiley:

Malix-Labs commented 11 months ago

hello guys! any update on this?

tbhaxor commented 11 months ago

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

debilin commented 9 months ago

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 :smile: Still waiting for deb package.

Bash-it / bash-it

Package Bash-it with a package manager #1819