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

Vendor #1776

Merged
merged 7 commits into from
Jan 27, 2021
Merged

Vendor #1776

merged 7 commits into from
Jan 27, 2021

Conversation

buhl
Copy link
Contributor

@buhl buhl commented Jan 8, 2021

In #1587 we talked about a way to handle vendor libraries.

Description

This PR vendors https://github.com/brettlangdon/git-vendor to vendor libs into bash-it.
This PR also includes the preexec lib and fixes to the source where needed. It also
includes a new plugin that can ring the terminal bell echo -e \a when a long running
process finishes.

Motivation and Context

As discussed in #1587 I would be nice to have a better controlled/versioned way of
including libraries in bash-it. There have been talks of git subtrees and loader
scripts to aid the loading of plugins. This PR includes these tings.

How Has This Been Tested?

I have been running with the new preexec lib for over a year in a personal fork of bash-it
the git-vendor lib is only used be dev who wish to add or update libs. It wont have any
effect on regular users of bash-it

Types of changes

  • New feature (non-breaking change which adds functionality)
    I feel I need to document how to add or update vendored libs. Where would be the best
    place for this?

Checklist:

  • My code follows the code style of this project.
  • If my change requires a change to the documentation, I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • If I have added a new file, I also added it to clean_files.txt and formatted it using lint_clean_files.sh.
  • I have added tests to cover my changes, and all the new and existing tests pass.

@NoahGorny
Copy link
Member

I am impressed by your efforts @buhl !
I agree that this needs to be documented somewhere. I guess the docs/development.rst can be a good location to include such information.

Also, if you add new plugins, please add then to clean_files.txt and lint them. I am unsure what to do about the vendored code, and we need to discuss whether we should lint it as well.

@buhl
Copy link
Contributor Author

buhl commented Jan 9, 2021

Thanks @NoahGorny!
I will be sure to tick that last boxes in the PR. I just wanted a go-ahead before putting to much work into it.
I don't think it's a good idea to lint the vendored code. It's libs we depend on, not source code we maintain.

@NoahGorny
Copy link
Member

Thanks @NoahGorny!
I will be sure to tick that last boxes in the PR. I just wanted a go-ahead before putting to much work into it.
I don't think it's a good idea to lint the vendored code. It's libs we depend on, not source code we maintain.

I am also unsure whether we need to vendor git-vendor as well. Regular users do not need it, so we might as well just document how to install and use it for developers, without actually vendoring it inside Bash-it.

@buhl
Copy link
Contributor Author

buhl commented Jan 9, 2021

Thanks @NoahGorny!
I will be sure to tick that last boxes in the PR. I just wanted a go-ahead before putting to much work into it.
I don't think it's a good idea to lint the vendored code. It's libs we depend on, not source code we maintain.

I am also unsure whether we need to vendor git-vendor as well. Regular users do not need it, so we might as well just document how to install and use it for developers, without actually vendoring it inside Bash-it.

Sure, I guess that's a reasonable requirements for a developer.

@cornfeedhobo
Copy link
Member

I really like where this discussion has gone. I notice that we're replacing the preexec library with a forked, and presumably better, version. Could we add erichs/composure to this PR as well?

@buhl
Copy link
Contributor Author

buhl commented Jan 9, 2021

@cornfeedhobo I don't see why we couldn't update composure as well once we landed on how to vendor libs.
But I think I would be more comfortable doing that in a separate PR (which I will gladly do once this is settled).

@cornfeedhobo
Copy link
Member

cornfeedhobo commented Jan 9, 2021

@buhl My thinking was that since you're already doing two big changes, might as well as a third. In the opposite direction of breaking up significant changes, maybe we should update preexec in place, and then do vendoring then? Especially considering the diff between the changed preexec library and the updated composure one.

@NoahGorny
Copy link
Member

I think we should remove the vendoring of git vendor, CR and merge this, and then continue with another vendoring PR of composure

@buhl
Copy link
Contributor Author

buhl commented Jan 9, 2021

@cornfeedhobo I am comfortable with the preexec changes for two reasons.

  1. I have been using this since April and have had no issues.
  2. Very little in the bash-it source code actually uses preexec.
    Composure on the other hand is AFAIK used in all plugins, aliases and bash_it.sh so I feel that is a bigger change.
    However I don't think the change will be a problem, I would just like to isolate it to it's own PR.

@cornfeedhobo
Copy link
Member

@buhl those are good reasons. Thanks again for your contribution!

@buhl
Copy link
Contributor Author

buhl commented Jan 9, 2021

@NoahGorny @cornfeedhobo Sorry for the rebase. I had to make sure it could be done to give more clean PR's
Turns out it's a bit messy to de rebasing with subtrees. It should however, only be necessary when preparing a PR for a clean merge.
But I do think we/I need to play a bit more around with subtree before adding it to bash-it.
I have also updated the documentation regarding this issue. But it seems the tests for these are failing. I will look into this.
Other than that I removed git-vendor and added some files to clean_files.txt and checked that my changes also worked with the barbuk theme as it used preexec

@buhl
Copy link
Contributor Author

buhl commented Jan 9, 2021

I will try to make a test of the plugin I added as well.

@buhl
Copy link
Contributor Author

buhl commented Jan 10, 2021

I don't know why the lint is failing. Running the same script locally works.

@cornfeedhobo
Copy link
Member

cornfeedhobo commented Jan 10, 2021

@buhl Hmm, barbuk should already be cleaned if you rebased off master correctly. Maybe rebase again?

The only other thing I can guess is that you've run into the same shfmt bug a few of us have. Essentially, our choice of formatting flags is causing a bug that adds whitespace on the first run in places you would not expect, like in bracket tests ([[]]). I've filed a bug upstream, but for now you'll just have to run shfmt like a dozen times on all the files you are adding.

@buhl
Copy link
Contributor Author

buhl commented Jan 11, 2021

Thanks @cornfeedhobo, It was an error on my part 🤦

@buhl
Copy link
Contributor Author

buhl commented Jan 11, 2021

I think maybe I should rebase this branch into fewer commits to make it more neat.
But @NoahGorny and/or @cornfeedhobo could I get some comments on the code and documentations?
I must admit that the trouble with rebasing a feature branch that is behind master makes me hesitate a little in recommending subtrees as the way to go for vendoring code.
I have also looked at https://github.com/ingydotnet/git-subrepo but AFAIK it doesn't support releases (as in tags) and it is overall a little more clumsy to use compared to git-vendor. However it creates a more clean git history 🤷

@cornfeedhobo
Copy link
Member

cornfeedhobo commented Jan 11, 2021

@buhl no problem. I should have some free time in a few hours and will take a look.

Copy link
Member

@nwinkler nwinkler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple of minor comments...

docs/development.rst Outdated Show resolved Hide resolved
Copy link
Member

@NoahGorny NoahGorny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nits from me, otherwise LGTM

test/plugins/xterm.plugin.bats Outdated Show resolved Hide resolved
docs/development.rst Show resolved Hide resolved
@NoahGorny
Copy link
Member

ping @buhl 😄

@buhl
Copy link
Contributor Author

buhl commented Jan 16, 2021

Sorry! My analog life called. I will try to fix the last few things and rebase the branch to make it merge ready tomorrow 😊

@buhl buhl force-pushed the vendor branch 5 times, most recently from 5ff2048 to 5809d92 Compare January 17, 2021 14:13
@buhl
Copy link
Contributor Author

buhl commented Jan 17, 2021

@NoahGorny I think it's about ready.
I did a rebase/force push to make the history a little nicer. So if you have pulled my branch be sure to delete it locally before pulling again.
I added a little more documentation. Other than that I think it's good to go?

Copy link
Member

@NoahGorny NoahGorny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@buhl I left you a small comment, other than it LGTM

BTW, I see the git-vendor is not actively maintained, this is quite concerning, but if the tool works, we can use it and just fork it if needed

@buhl
Copy link
Contributor Author

buhl commented Jan 22, 2021

@NoahGorny Sorry, must have misser your comment. Will look at it tomorrow.

Regarding git vendor I referenced https://github.com/Tyrben/git-vendor because I looks like an actively maintained fork of the other repo. If the fork goes stale as well we can consider maintaining a fork our selfs.
But for now Tyrben is active in brettlangdon repos an seems to port pull requests to their own fork.

@NoahGorny
Copy link
Member

@NoahGorny Sorry, must have misser your comment. Will look at it tomorrow.

Regarding git vendor I referenced https://github.com/Tyrben/git-vendor because I looks like an actively maintained fork of the other repo. If the fork goes stale as well we can consider maintaining a fork our selfs.
But for now Tyrben is active in brettlangdon repos an seems to port pull requests to their own fork.

Oh, I see, so ignore my comment, and instead add a note about the fact that we use the maintained fork and not the original repo (going to the supplied link might be confusing otherwise, I got quite confused)

Anyway, well done! I hope we can merge it soon and include all vendored code in this format

buhl added 2 commits January 23, 2021 18:28
…it 7884535

git-subtree-dir: vendor/github.com/rcaloras/bash-preexec
git-subtree-split: 7884535ed423ac27d3b6b473c61b1fe41905aca1
git-vendor-name: preexec
git-vendor-dir: vendor/github.com/rcaloras/bash-preexec
git-vendor-repository: https://github.com/rcaloras/bash-preexec
git-vendor-ref: 0.4.1
Added a vendored lib loading routine in bash-it.sh
Added documentation on how to vendor libs in bash-it
Added and fixed plugins using preexec
Added tests for two plugins
Removed the old preexec lib
@buhl
Copy link
Contributor Author

buhl commented Jan 23, 2021

Hmm, themes/atomic/atomic.theme.bash and themes/base.theme.bash are failing the lint check. I did not touch these files but should I fix the errors in this PR?

@buhl
Copy link
Contributor Author

buhl commented Jan 23, 2021

@NoahGorny I added some text about the different git vendor repos. I think I have resolved all pending questions so now there is only the linting errors left mentioned in my previous comment.

@NoahGorny
Copy link
Member

Hmm, themes/atomic/atomic.theme.bash and themes/base.theme.bash are failing the lint check. I did not touch these files but should I fix the errors in this PR?

Running locally, I saw shfmt complaining about the xterm plugin only, I added a fix commit, and I'll review this again now

Copy link
Member

@NoahGorny NoahGorny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@buhl I made a couple of change, but now its LGTM

I'll let @nwinkler @davidpfarrell @cornfeedhobo voice their opinions as this is a big change. If we merge this, we should move all of our vendored code to be used in this pattern. I will help us control it!

@buhl
Copy link
Contributor Author

buhl commented Jan 23, 2021

Ah, I missed the linting errors in the xterm test because I saw errors in the two themes mentioned in an earlier comment.
Thanks for fixing them 😄

I will gladly help moving the other libraries to this vendor method if its accepted.

@nwinkler
Copy link
Member

Looks good to me!

@NoahGorny
Copy link
Member

Its about time we merge this, 🥳
@buhl you are welcome to move more things into the new vendor directory 😄

I added a lint check of the init.d directory, as it is our code

@buhl
Copy link
Contributor Author

buhl commented Jan 27, 2021

Sounds great 😄
I think I will have some time the upcoming days to vendor some libraries.
I have started a new issue #1818 to keep track of this process.
For now there is only only external library on the list

Also fix and lint the directory.
This is our code, and as such, should be linted.
@NoahGorny NoahGorny merged commit 2388c74 into Bash-it:master Jan 27, 2021
@buhl buhl deleted the vendor branch January 27, 2021 22:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants