add pylint

[wendellwt]

Hello, Thank you very much for the starter kit! I was finally able to run nvim with pylint and without pyright. (I found pyright very difficult to work with and configure, and it was extremely verbose).

I was able to get nvim to use (only) pylint thanks to your starter kit and with some help from jdhao

Would you be interested in including this in your starter kit?

I'm not sure if the section of nvim-lspconfig.lua could be made into its own file; I'm not familiar with Lua configs. But at least this works for me.

Thanks again.

[bcampolo]

@wendellwt That's great! I'm glad the Starter Kit was helpful. I'd love to include something like this but I'm still debating how I want the repo structured for different languages. I think I want to keep the "base" Starter Kit general purpose and then branches or tags for different kits, like Python Starter Kit. Either way I'll be using some/all of what you've done here so I appreciate the effort!

[wendellwt]

Great!

The pylint changes that I made are in just one phrase/stanza/section of your nvim-lspconfig.lua. Would it be possible to put that into a separate file? What if that file was named pylint.lua_optional, or something like that, with the instructions to rename that to pylint.lua if you really wanted that functionality?

This attached file does not work, but something like this is what I had in mind: pylint.lua.txt

I'll work on correcting that file, unless you can easily spot the errors.

[bcampolo]

@wendellwt With the holidays it's probably going to be a couple of weeks before I really get into this, but I was thinking about two possible directions for anything that is language/framework specific:

1. Basically what you suggested, having separate commented out sections or separate files that you need to swap in/out. This has the benefit of being part of 'main' and not having to sync across branches. The main drawback that I foresee is once we've added a dozen or so languages, this will get very messy and you'll have to scour the repo looking for which sections to uncomment.
2. The other approach is what I was hinting at before where maybe there is a 'python' branch that is based on 'main', but everything is updated in place to support python, e.g. the README has sections describing any extra python stuff, the lspconfig has all of the correct python servers, treesitter has the right settings, etc. Then on the 'main' README there will be instructions on how to use the language-specific Starter Kits, e.g. To see the Python Starter Kit, click here: which would point to the python branch, but in the same view as the main Starter Kit, where it lands on the README page with the code at the top specific to that branch.

I'm heavily leaning towards option 2, but need to play around with it a bit when I have more time. I really do appreciate the pull request and will use as much of it as I can when I get a bit more time to dive into this some more.

Thanks again!

[dave42w]

I'm thinking about this because I want rust support. It would be nice if there were a possibility for a a plug-in file approach for language support just like lazy uses. Then we could have a directory lsp-plugins and if I put a file called rust in there then I get to include the lua code to configure all the parts for full rust support. Similarly for python. Having to tackle this in GIT seems more work and less flexible.

[bcampolo]

@dave42w I see your point. At the same time I think this Starter Kit should not become a full-fledged distro, but I agree it would be nice if there was a quick way to say I want x, y, and z. I was thinking eventually there would be a 'Python Starter Kit' which was really just the python branch of this repo and if someone wanted a Rust Starter Kit they can contribute a rust branch, but to your point, if you want more than one you then need to mix/match/merge multiple branches. I'm open to ideas, but definitely don't want the Starter Kit to become too complex for new comers. It should pretty much just work out of the box and these other parts would somehow be optional.

[wendellwt]

When starting a new VueJS project, there is a startup script that asks some yes/no questions about the configuration, and then it constructs the template vuejs project:

$ npm create vue@latest
Vue.js - The Progressive JavaScript Framework

√ Project name: ... another_project
√ Add TypeScript? ... No / Yes
√ Add JSX Support? ... No / Yes
√ Add Vue Router for Single Page Application development? ... No / Yes
√ Add Pinia for state management? ... No / Yes
√ Add Vitest for Unit Testing? ... No / Yes
√ Add an End-to-End Testing Solution? » No
√ Add ESLint for code quality? ... No / Yes

Scaffolding project in C:\cygwin64\home\wendell\pkgs\vite_starter\another_project...

Done. Now run:

  cd another_project
  npm install
  npm run dev

Would you consider something like this for the starter kit?

[bcampolo]

@wendellwt That's a very interesting idea. I've seen this done in a number of projects over the years and didn't even think of it. Thanks

[bcampolo]

I just released my first version of the "python" branch. After a lot of research and tinkering I decided to go more in the pyright direction. I originally tried python-lsp-server but it just didn't feel "right" to me. Check it out and let me know what you think and if there are tweaks that can make it easier to turn on and off optional parts I think that would be ok.