new plugin: config plugin will load/save your bash-it configuration

[boneskull]

So basically what you do:

1. Create an empty repo on GitHub or whatever
2. Clone bash-it and run install script as per the directions
3. Ensure you have config plugin enabled
4. save-bash-it will prompt for your repo URL, then it will save information on your enabled plugins, aliases and completions
5. It will also put your custom files under version control
6. It also puts your .bash_profile under version control
7. It adds everything to the local repo it just made (living in $BASH_IT/.config), commits, then pushes

So if you change your .bash_profile, enable/disable any plugins, or create custom files, run save-bash-it again and your changes will be pushed to your repo.

Then, log into some other machine,

1. Repeat steps 2-3 above
2. load-bash-it will prompt you for your repo URL, clone your repo, then read the config files and enable whatever
3. It will also stick your custom things back where they go, if you have them
4. It will overwrite your .bash_profile, if you have that too

This works for me, but may be a bit heavy-handed in places. Could use some prompts or something because of the files getting overwritten and rm -f'd all over the place.

Let me know what you think.

[boneskull]

This is what a config repo looks like

[tswicegood]

Can you use the function _config-read-git-url () syntax here? PR #315 fixed all of these to avoid parse errors that we were exposing ourselves to.

[tswicegood]

This looks pretty awesome and something we definitely need. I actually ended up writing my own simple thing just parsing the output to bash-it enabled … to handle a transition to a new computer. Do have a couple of questions to make sure I know what's going on, but I definitely wanna get this in.

[boneskull]

@tswicegood Hi Travis.

I hope you can use this PR. Unfortunately, I stopped using bash-it after forking Mathias' dotfiles, which really clicked for me. I had a few issues with bash-it:

1. It was difficult to manage a custom configuration across installs/environments, and work with VCS. I think this is due, in part, to the whole "symlink-to-enable" concept. Perhaps you've considered this before, but I think a configuration file would be more portable.

My idea is that bash-it would basically come with nothing. You modify a config file by hand or via command line (like bash-it install git would install Git plugins), and upon reload, the appropriate scripts are fetched from GitHub (or some server, anyway) and installed. Users could execute bash-it update to fetch any changes to the published plugins. Kind of like a package manager for bash, if you will.

2. Could not figure out a good way to copy/link arbitary dotfiles (think .gitconfig or .inputrc) into my HOME, or scripts into HOME/bin/.
3. I don't understand the point of separating themes, plugins, or completion. I do understand that these are categories, but practically speaking, it's all just bash. (My idea above would assume every "thing" to have a unique name; perhaps themes are prefixed with theme- or whatever.) I think removing the categorization and enforcing uniqueness would make things more simple.

If these issues are addressed I'd definitely come back to bash-it. I apologize if I'm not going to be updating this PR, because I don't have the time right now; I can anwer any questions you may have, however.

thanks for the good work
Chris

[nwinkler]

To address the second of your items (dotfiles), I'm using Homesick, which allows the linking of dotfiles and directories into your home directory. My Dotfiles repo is based on that.

I've used a script in my Dotfiles repo to sync enabling/disabling plugins across installations. It works, but isn't great, since it requires manual work to update. A command to do the same would be fantastic, if it was possible to sync using Homesick even better.

[nwinkler]

For what it's worth, I think the real benefit of bash-it is the ease of separating functionality into files in an organized manner, which is something that's missing from most other dotfile repos. I don't want to end up with a huge file that contains all of the aliases. Bash-it lets me select the ones I want to use, and it allows me to be flexible with that, e.g. for different configuration for home and work. I haven't found that with simple dotfile repos.

[boneskull]

@nwinkler Agreed, that's a 👍 for bash-it.

[tswicegood]

Hey @boneskull -- thanks for the update.

Since @nwinkler mentioned point 2, let me elaborate. I think something like Homesick is probably where the code for managing dotfiles belongs. bash-it (at least as I see it) is meant to handle simple bash setup that falls into a few categories:

• aliases
• functions/plugins
• auto-completion
• theming

I don't think managing things like .gitignore and .gitconfig files is the right thing for bash-it to do. Which kind of bleeds into point 3: it is all just bash, but providing the breakdown above really allows you to pick and choose how you want to use the project.

To address point 1: I actually really dig the idea of allowing code to percolate outside of the main repo. That'd definitely speed up iteration as people could release their own code without having to wait to get it merged into this repo, but would make discovery a lot harder. You might have some awesome plugins, but how would people find them? Going the available + enabled route allows us to ship the kitchen sink, but then you can choose what you want to turn on instead of everything being there (which is how it used to be).

Hope you consider sticking around. We could definitely use some new blood and ideas helping us move this forward. I think bash-it's pretty awesome, but I also know there's tons of room for improvement. This PR shows a lot of promise and ability on your end… we could use another set of hands making it even more awesome.

[boneskull]

To address point 1: I actually really dig the idea of allowing code to percolate outside of the main repo. That'd definitely speed up iteration as people could release their own code without having to wait to get it merged into this repo, but would make discovery a lot harder. You might have some awesome plugins, but how would people find them? Going the available + enabled route allows us to ship the kitchen sink, but then you can choose what you want to turn on instead of everything being there (which is how it used to be).

I was originally thinking that simply keeping the extensions in their own repo and installing on-demand would work (like Hubot or something). But then you still have the PR problem.

So you'd need a registry. I haven't written a registry myself, but it doesn't seem very difficult to have something basic.

Your package manager registry could be a pretty simple script living on, say, Heroku. It would respond to POST and GET requests. You could use a filesystem db or some simple key-value db (like maybe Redis). POST requests would look like:

POST http://registry.bash-it.io/
name=myExtension&repository=https://github.com/me/my-bashit-extension.git

At this point it would check If myExtension does not yet exist in the store. If it does not, check the URL and make sure it's a valid Git repo. If so, add to store.

GET request:

GET http://registry.bash-it.io/myExtension

returns plain text:

https://github.com/me/my-bashit-extension.git

To the user, they would bash-it install myExtension, and this would perform a curl request against the registry, as in the GET example above.

Bash-it would receive the plain-text repo URL, then clone this repo, checkout the latest tag, then install. The user could specify a different tag or branch, if they wish. This information could be saved in a run control file in the user's home dir. To install/reinstall your configuration, issuing a bash-it install (no parameter) could read the run control file and install each extension previously specified.

This sounds pretty simple to me, but maybe I'm overlooking something.

[NoahGorny]

this is very interesting, but kinda superseded by #1865