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

Bashit light weight for servers #1825

Closed
tbhaxor opened this issue Feb 3, 2021 · 17 comments
Closed

Bashit light weight for servers #1825

tbhaxor opened this issue Feb 3, 2021 · 17 comments

Comments

@tbhaxor
Copy link
Contributor

tbhaxor commented Feb 3, 2021

Expected Behavior

There should be a light version of bashit for servers with essentials like

  1. 3 - 4 simple themes that loads fast
  2. few lines in .bashrc so that the shell prompts faster
  3. essential completions / plugins only
  4. server specific functionality like
    1. add new vhost
    2. iptables aliases and more

Current Behavior

The current size is 3.4 mB which is kinda huge for servers. There we need some light weight solution that runs faster

Possible Solution

From the current repo, purge all the unnecessary files and add few servers specific functionalities

@tbhaxor
Copy link
Contributor Author

tbhaxor commented Feb 5, 2021

@nwinkler @NoahGorny any ideas on this?

@NoahGorny
Copy link
Member

Is the performance an issue or the repo size?

If the performance is an issue, we can just add a new installation option for servers, which enables only the most suitable plugins and themes for servers

@tbhaxor
Copy link
Contributor Author

tbhaxor commented Feb 5, 2021

Is the performance an issue or the repo size?

If the performance is an issue, we can just add a new installation option for servers, which enables only the most suitable plugins and themes for servers

Basically it's both. But I would like to stick to performance issue

@cornfeedhobo
Copy link
Member

cornfeedhobo commented Feb 5, 2021

IMHO, this is a duplicate of packing up for distribution, because when doing so we would not include any git history, making the install very lightweight.

However, in the meantime, this point about changing default plugins might be worth exploring. We could open a PR to add an install flag for this, as @NoahGorny suggests.

Edit: could also try to automate this by testing for a headless environment, e.g. no x11 or wayland.

@nwinkler
Copy link
Member

nwinkler commented Feb 8, 2021

The repo size issue is caused by

  • the long history of Bash-it, and
  • some binary files (images) that crept into the Git history. Removing those would mean rewriting the Bash-it history.

To your point, @tbhaxor, "purging all the unnecessary files" will not fix this, as it will simply add more history, the cloned repo size will not really shrink. The current installation instructions recommend to do a shallow fetch, which results in 1.2 MiB (which still seems rather large - might be worth investigating).

TBH, with today's download speeds, a download size of 1 MiB (or even 3 MiB) shouldn't be a problem at all. You've got a point about the initialization time - but as mentioned, that can be handled using the installer.

@davidpfarrell
Copy link
Contributor

Hi Team, Okay I've been grinding on this ... I see @tbhaxor mentioned their main concern was performance, but my thoughts are mostly related to install size ...

Reduced runtime overhead

If the performance is an issue, we can just add a new installation option for servers, which enables only the most suitable plugins and themes for servers

I think there could be value to having install profiles with different defaults for enabled components.

There's also value in a --no-components option that installs with no components enabled.
Q: Does that exist already?

... which enables only the most suitable plugins and themes for servers

I don't think we enable any themes by default, right? So the user/admin has full control over that.

Reduced Install footprint

I think the use-case for having Bash-it installed with a reduced footprint is valid.

I don't find much value in the idea of a separate, "lightweight" distribution. Until Bash-it can download+install components on-demand (ala brew per se), you'll never please everyone with the component choices that go into a sub distro.

What I think would be valuable is either a built-in function(s), or a documented process, for removing unused components and unneeded files, etc.

For instance, it would be pretty easy to Detect and Delete aliases, completions and plugins that were not Enabled.
You could imagine a function like:

$ bashit remove plugin ruby

$ bashit remove plugins --all

$ bashit remove plugins --not-enabled

Themes would be a bit harder, because some themes rely on others.

$ bashit remove theme simple

$ bashit remove themes --all

$ bashit remove themes --all-except powerline,powerline-plain

Unneeded files in release archives

Additionally, I feel our Releases contain a lot of files that are likely not needed by the average user:

.ackrc
.editorconfig
.gitattributes
.gitignore
.gitmodules
.pre-commit-config.yaml
.readthedocs.yml
.shellcheckrc

.github/

clean_files.txt
lint_clean_file.sh

test/
test_lib/

NOTE: I might consider the docs/ folder on this list as well

I recommend we consider removing these files/directories from our official release archives. Users who want to contribute should be encouraged to checkout from source, and they would pickup these files that way.

Lastly, you could also imagine a bash-it command to remove these files (and the .git/ folder itself) post-install:

$ bashit --reduce-footprint

NOTE: --reduce-footprint is merely a place-holder as I could not think of a more-useful name in the moment.

NOTE: I suspect users of this action would like the ability to consider the docs/ folder for removal as well, so we would want some way to accommodate that, something like

# Exclude docs by default
$ bashit --reduce-footprint --include-docs

# Remove docs by default
$ bashit --reduce-footprint --keep-docs

# Separate action for removing docs
$ bashit remove docs

User-created distros

One of the goals with these tools would be to allow users to easily create their own distros. With that idea in mind, we may also want to consider a Bash-it command to archive itself:

$ bashit archive /path/to/save/file.tar.gz

-DF

@tbhaxor
Copy link
Contributor Author

tbhaxor commented Feb 8, 2021

To your point, @tbhaxor, "purging all the unnecessary files" will not fix this, as it will simply add more history, the cloned repo size will not really shrink. The current installation instructions recommend to do a shallow fetch, which results in 1.2 MiB (which still seems rather large - might be worth investigating).

Currently we are using latest tag to determine the current stable version of bashit.

Why not we add a simple file that would download the tarball / zip from github released of latest plugin and extract it in the ~

Something like

curl https://github/bashit/install.sh | sh

Please note, there would be no frequent updates on server. As servers are meant to be keep running on lts versions unless there is serious security flaw in it (here bash interpreter)

@nwinkler
Copy link
Member

nwinkler commented Feb 9, 2021

Thanks for the summary, @davidpfarrell!

I think there could be value to having install profiles with different defaults for enabled components.

There's also value in a --no-components option that installs with no components enabled.
Q: Does that exist already?

The install.sh script has the --silent flag, which enables only a set of reasonable defaults, e.g. bash-it completion and the general aliases.

Install footprint: Do we really see value in saving a couple of megabytes here? The overall size of the Themes, Plugins, Aliases, and Completions is about 2 - 3 MiB in total. Do we really want to go through all this work to save a couple of KB here and there? The impact of having to handle the local Git changes when removing files seems unnecessarily complex - unless we convert the cloned repo to a non-Git folder and stop tracking local changes...

I agree that a lot of the development-related files like Editorconfig don't belong in a packaged distribution, but that's something we can cover as part of the packaging. A dedicated command for that feels like overkill.

@cornfeedhobo
Copy link
Member

Why not we add a simple file that would download the tarball / zip from github released of latest plugin and extract it in the ~

@tbhaxor This is an over-optimization. The current install path is also a "one liner". There just isn't a need for any of this concern. See #1819

@tbhaxor
Copy link
Contributor Author

tbhaxor commented Feb 9, 2021

I don't think we enable any themes by default, right? So the user/admin has full control over that.

@davidpfarrell By default bobby theme is enabled

export BASH_IT_THEME='bobby'

I don't find much value in the idea of a separate, "lightweight" distribution

For this we can use makefile approach

bash-it install  # default install
bash-it install --target server

Also, remove plugin is not required.

$ bashit --reduce-footprint

We can use something like

$ bashit purge-unwanted
$ bashit purge-unwanted --with-disabled plugins --with-disabled themes

This is an abstract idea

@tbhaxor
Copy link
Contributor Author

tbhaxor commented Feb 9, 2021

Ohk let's not make this complicated.

My whole point was, in servers we want very few things like

  1. iptables related alias or plugins
  2. systemd related plugins
  3. few themes (bobby is good)
  4. fast source-ing of .bashrc (it takes time when too many assets are enabled)
  5. bashit updation
  6. and more but not all 😄

We can use @NoahGorny's approach. I really liked that instead of creating separate repo or branch simply add flag. Nice thinking brother

@cornfeedhobo
Copy link
Member

Oops. Accidentally closed. Sorry about that 😅

@nwinkler
Copy link
Member

An install profile similar to the --silent option might be the right way then. Like I said, saving disk space (a couple of MiB at best) feels like overkill - the couple of extra files that are on disk but are not loaded will not hurt anyone.

Maybe a --minimal option for the installer is what we need, or a way to define custom profiles, e.g. --profile <profile_name>.

On the other hand, if you end up wanting the same config on every one of your servers, a backup/restore of your current configuration might be a smarter way to go about this. I'd like to point to this again: https://github.com/nwinkler/dotfiles/blob/master/home/bin/backup-bash-it - the resulting file can be backed up in Git and then run on any server where you want the same Bash-it configuration...

@NoahGorny
Copy link
Member

An install profile similar to the --silent option might be the right way then. Like I said, saving disk space (a couple of MiB at best) feels like overkill - the couple of extra files that are on disk but are not loaded will not hurt anyone.

Maybe a --minimal option for the installer is what we need, or a way to define custom profiles, e.g. --profile <profile_name>.

On the other hand, if you end up wanting the same config on every one of your servers, a backup/restore of your current configuration might be a smarter way to go about this. I'd like to point to this again: https://github.com/nwinkler/dotfiles/blob/master/home/bin/backup-bash-it - the resulting file can be backed up in Git and then run on any server where you want the same Bash-it configuration...

I really like the profile way. We can have default profiles that we distribute, and also allow users to save/load different profile to allow customized profiles

@NoahGorny NoahGorny mentioned this issue Apr 5, 2021
10 tasks
@tbhaxor
Copy link
Contributor Author

tbhaxor commented Feb 8, 2022

@NoahGorny How can I test this?

@gaelicWizard
Copy link
Contributor

@tbhaxor, create a new profile file named "minimal.bash_it" or similar. You could create a new branch and just edit default.bash_it and try install.sh --silent on a server and see how you like it.

I think the biggest candidate for removal is the alias completion, but there's really not much in there. Maybe alsö set $BASH_IT_THEME?

@NoahGorny
Copy link
Member

Closing as #1865 solves this

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

No branches or pull requests

6 participants