search

m15a / flake-awesome-neovim-plugins

Nix flake of Awesome Neovim plugins
BSD 3-Clause "New" or "Revised" License
51 stars 11 forks source link

Automate removal of officially maintained plugins #55

Closed m15a closed 6 months ago

m15a commented 2 years ago

It would be nice to automate its simple workflow.

Workflow

  1. Find officially maintained plugins in nixpkgs-unstable.
  2. Add them to blacklist.txt.
  3. Add them to onceHereButNowOfficiallyMaintainedPlugins section in overrides.nix.
Alexnortung commented 2 years ago

Would it make sense to wait for automatic removal until the plugins are in a stable version of nixpkgs? Some users may not follow the unstable channel and thus need to pin the version of this repo, resulting in them having outdated plugins and not being able to use newly added plugins.

I am not sure how fast nixpkgs backports plugins, but if they do it quite fast, then it should not be a problem.

jooooscha commented 2 years ago

In my humble opinion, this is not advisable. Wouldn't it be much nicer to have one repo (this one) that contains "all" plugins that is always up to date independently from the nixpgks?

Alexnortung commented 2 years ago

Imo the name of the repo is EXTRA plugins, thus it should contain just extra plugins. Keeping the repo as clean as possible would be nice.

I think that a flake that would keep track of all plugins would be nice, but I don't think it is the scope of this repo.

jooooscha commented 2 years ago

Why should it be not in the scope of this repo? I think the work by @m15a to automate things as much as possible is a very good basis for this. Sure, actually having all plugins in one repo is a bit much, but I don't see why we should not go into that direction.

This repo could become a central repo for all neovim plugins related nix problems. For example one could just look here to know if a plugin is already available for nix and would not have to check both repos. Also, its much easier to keep the plugins up to date here than in the huge nixpkgs.

If we split management of neovim plugins into this repo and the nixpkgs, we would also need to keep track if plugins are not supported anymore, which would be a bit harder to automate, I think?

Finally, I don't see the downsides of having "too much" plugins in this repo. Does it have scalability problems? Does it clash with nixpkgs?

And yes, the name contains extra, but I don't see how this should influence the decision.

PhilTaken commented 1 year ago

This repo could become a central repo for all neovim plugins related nix problems. For example one could just look here to know if a plugin is already available for nix and would not have to check both repos. Also, its much easier to keep the plugins up to date here than in the huge nixpkgs.

I think this is a great opportunity offload some maintenance work from the nixpkgs repo. I agree in all points.

we would also need to keep track if plugins are not supported anymore, which would be a bit harder to automate, I think?

relatively easy to setup would be a nixos-vmtest for each plugin by itself (with all dependencies of course)? :thinking: not sure if the effort of spinning up a vm for every single plugin would be worth it though

Does it clash with nixpkgs?

sometimes it does with duplicate definitions, at least the way I use it, will have to look more into that (probably my fault)

m15a commented 6 months ago

GitHub REST API rate limit is 5k/hour, while Awesome Neovim currently has less than 1k plugins. At maximum 2 requests are consumed per plugin, so it is feasible to ship with all plugins.

https://github.com/m15a/flake-vim-extra-plugins/blob/f0ff88e3bdd2ad1b2158b5e39ceeb700f2ab417e/data/stats/awesome-neovim/1712527501.json#L7

I'll remove the bonds later.