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

vimplugins: update.py supports GitHub Access tokens; add completion-nvim, completion-treesitter #91656

Merged
merged 5 commits into from Jul 8, 2020

Conversation

colemickens
Copy link
Member

Motivation for this change

Update vimplugins and add:

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

Copy link
Member

@teto teto left a comment

Choose a reason for hiding this comment

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

so last time I merged a neovim plugin for lsp, there were some complaints that we shouldn't package for an unreleased software. nvim 0.5 is still a few months away but works quite well already so I still believe it's fine to merge.

@colemickens colemickens force-pushed the vimplugins branch 4 times, most recently from 513f320 to 31938c7 Compare July 5, 2020 09:13
@colemickens colemickens changed the title vimplugins: update, add completion-nvim, completion-treesitter vimplugins: update.py supports GitHub Access tokens; add completion-nvim, completion-treesitter Jul 5, 2020
@colemickens
Copy link
Member Author

I've rebased this and also made ./update.py use GITHUB_API_TOKEN if defined. This makes updating considerably faster since you have use higher parallelism without 429s.

I think there are more than a few people using neovim 0.5, particularly for the features that these plugins revolve around. It certainly wouldn't be the first unstable thing packaged in nixpkgs, and at least one of them has a tagged release. Hopefully this can be merged. Thanks for considering/reviewing!

pname = "completion-nvim";
version = "2020-07-05";
src = fetchFromGitHub {
owner = "haorenW1025";
Copy link
Member

Choose a reason for hiding this comment

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

a few plugins recently moved under the org "nvim-lua" so htis is the new home

@teto
Copy link
Member

teto commented Jul 5, 2020

while at it would you mind packaging https://github.com/nvim-lua/lsp-status.nvim

@colemickens
Copy link
Member Author

@teto Sure, I've redone the PR with lsp-status.nvim included as well.

Also, I was able to use -p 16 to redo this, which was 16 times faster than can be achieved without GITHUB_API_TOKEN.

@colemickens
Copy link
Member Author

this iteration isn't ready for merging, btw.

@colemickens
Copy link
Member Author

Looks like I had missed another dependency of completion-treesitter.

@teto your requested plugin breaks my system config (it looks like maybe vimplugins tests that vim can startup properly?) When I point at this commit, it works. Maybe you can file an issue/pr on lsp-status.nvim for this? I don't quite have context, or time to test this outside of nixpkgs. colemickens/lsp-status.nvim@3982991

I'm going to back out the lsp-status-nvim commit and push what works.

@@ -71,6 +70,15 @@ def f_retry(*args: Any, **kwargs: Any) -> Any:

return deco_retry

def mkreq(url: str) -> urllib.request.Request:
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
def mkreq(url: str) -> urllib.request.Request:
def makeRequest(url: str) -> urllib.request.Request:

urllib.request.urlopen(
self.url(f"blob/{self.branch}/.gitmodules"), timeout=10
).close()
req = mkreq(self.url(f"blob/{self.branch}/.gitmodules"))
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
req = mkreq(self.url(f"blob/{self.branch}/.gitmodules"))
req = makeRequest(self.url(f"blob/{self.branch}/.gitmodules"))

@Mic92
Copy link
Member

Mic92 commented Jul 7, 2020

Should the token be made a requirement? I mean without it, one does run into request limits quite fast, so it is not really usable.

@colemickens
Copy link
Member Author

@Mic92 I don't know. I didn't want to make a "breaking change" if i I didn't have to. It does update with -p 1, it's just slow. I'd rather leave it to another PR, to be frank. (I went ahead and did this next round of fixups and rebased/pushed.)

@gvolpe
Copy link
Member

gvolpe commented Jul 8, 2020

Any chance you can update coc-metals as part of this PR as well? The current version in Nixpkgs is super outdated. The new repository is https://github.com/scalameta/coc-metals

I tried to update a few plugins but I was also blocked by #91339

@colemickens
Copy link
Member Author

I don't think so, sorry. I've already churned this PR once for a change I wound up having to back out. I'd really like to see this merged so we can unblock everyone.

@gvolpe
Copy link
Member

gvolpe commented Jul 8, 2020

No problems, I'll try to put up a follow up PR.

@flokli
Copy link
Contributor

flokli commented Jul 8, 2020

Let's merge this 👍 Thanks for your work!

@flokli flokli merged commit 62ff70e into NixOS:master Jul 8, 2020
@gvolpe
Copy link
Member

gvolpe commented Jul 12, 2020

This still doesn't work for me. I have set up a GITHUB_API_TOKEN and some packages managed to be downloaded at first but then again Github doesn't seem to like the amount of requests.

<urlopen error [Errno 113] No route to host>, Retrying in 3 seconds...
<urlopen error [Errno 113] No route to host>, Retrying in 3 seconds...
<urlopen error [Errno 113] No route to host>, Retrying in 3 seconds...
<urlopen error [Errno 113] No route to host>, Retrying in 3 seconds...
<urlopen error [Errno 113] No route to host>, Retrying in 3 seconds...
<urlopen error [Errno 113] No route to host>, Retrying in 3 seconds...
<urlopen error [Errno 113] No route to host>, Retrying in 3 seconds...

@gvolpe gvolpe mentioned this pull request Jul 12, 2020
9 tasks
@colemickens
Copy link
Member Author

Unless I made some other coding error, "No route to host" is a very different error condition than an HTTP 429.

@Mic92
Copy link
Member

Mic92 commented Jul 12, 2020

Agreed. Sounds like a local network issue.

@gvolpe
Copy link
Member

gvolpe commented Jul 12, 2020

I don't think I have any network issues, it would be nice if someone else could try and see if this works for them.

@colemickens
Copy link
Member Author

I just ran it https://asciinema.org/a/mFnijt0sBehQyxZWUeRKb2Iu2 (and rotated the access token).

@gvolpe
Copy link
Member

gvolpe commented Jul 12, 2020

Wow, that really works for you! Thanks for that. Any chance you could try and make the same changes I made to vim-plugin-names here and then run the script again?

It's really late in my timezone but I promise to post what happens on my end tomorrow first thing. I wish this worked for me too...

@colemickens
Copy link
Member Author

Sure, let's move the conversation over to your PR. Maybe a new issue would be best if you (or anyone) winds up finding something wrong with the update script.

@colemickens colemickens deleted the vimplugins branch December 30, 2022 01:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants