Maintainer needed (at least for a while...)

[galaunay]

To anyone interested in Elpy's development.

I have been less and less able to give Elpy the attention it deserves over the last year. The truth is I developed hand injuries, and I need to stay away from my keyboard as much as possible. This is unfortunately not compatible with maintaining Elpy properly...

I am a bit frustrated by not being able to fix the code that needs to be and implement the nice enhancements that could be done: LSP, refactoring, python 3.9 new features, ... I really hope some people will be able to take over. If any of the current collaborators (@rgemulla, @gopar, @sten0) or somebody else would be willing to do so, please reply here, or contact me directly.

[akshaybadola]

Hi @galaunay. Sorry to hear about your hand. I would love to contribute but I think the project is so large that I won't be able to do it alone. If some other people also are there I think it is feasible as the list of issues is now pretty big and bug fixes are badly needed and would be very hard to do it by one person.

[rgemulla]

I am willing to continue to help maintaining the elpy-shell module as time permits (just mention me on the relevant issues). I am not using any other parts of elpy right now, so I am not really up-to-date anymore.

[gopar]

@galaunay extremely sorry to hear about your injuries. You've done pretty awesome work maintaining elpy. Unfortunately for me, I won't be able to help out much. (Switched jobs, and going to be busy)

If anyone here wants to start helping out, then please do so. You can tag me in PR's and I will start reviewing them (Please ping me if I don't, don't worry if you think i'll be bothered :)

I'll have to revisit the code base again since its been a while since I last looked over it.

Another form of helping out is also helping out with answering questions in the issue tracker, that greatly gives you insight as to how ppl are using elpy and how to get into the mindset on how to expand elpy to fit/extend those use cases.

[sten0]

@akshaybadola, I'm not sure how much help I'll be with my limited experience (definitely not enough to maintain the project!), but I'd like to help with whatever I'm able to. My interest is primarily in the the Debian package, and my feeling is that it's not ready for release with Python 3.9 (CI failures, plus a couple issues at this project that look related), and will only satisfy the requirements of the most basic users. My fuzzy deadline is 10 March for a Debian package using tagged release that resolves these issues.

Does this proposal sound sensible: by the coming weekend, build a roadmap of issues to solve for the next release; then, anyone interested in fixing an issue can claim one. Next, merge all PRs that are part of this effort to a feature branch (each PR should resolve one unit test failure and introduce no regressions), test it a bit, and make a release of this good state of Elpy.

I can help with the low-hanging fruit, but that's generally the fun stuff, so I'll understand if no one is interested in this proposal :-)

@galaunay, would it be fun to provide support and guidance by attaching voice recordings to the issues (or maybe dictation software, if that software is reliable enough by now?)? It strikes me as a neat twist on "benevolent dictator"/maintainer ;-)

[akshaybadola]

@sten0, that sounds like a good plan. I would like to see how many of the issues the fork from @gfederix has fixed and if he's interested in sending a PR, because I think some issues have resolved there. From there one one can look at remaining issues and/or features and take it from there. I hope @galaunay can provide some broad direction in where the project is to head, as I would really like to this project continue. I tried one other lsp based jedi plugin and was not left particularly enthused.

[gfederix]

Hi all! Yeah my fork... I changed jobs at the beginning of the month so I have serious time management problems. But I still want to add a couple of my wishes to the project. PR is still in my immediate plans.

[galaunay]

@akshaybadola Thanks for offering to help, you are right that there is much to do, even just to keep Elpy working. I should have taken action sooner, so this is on me... I will try to make a summary of what needs to be addressed in priority (reading issues and make short notes about them is something I think I can do). We will probably also need a tag system that will allow to focus on what's important. Maybe @sten0 could then help pinpoint the issues that need to be addressed in priority for the debian release ? If anybody has identified important issues to deal with in priority, we can start a list here.

@rgemulla It is nice if you can keep an eye on the elpy-shell related things, it is not the simplest part of Elpy to understand for somebody new. Thanks.

@gopar That would definitely help if you could do some reviewing now and then, I leave the mighty stick of merging power to you :).

@gfederix Thanks for that, we will be happy to merge your patches.

@akshaybadola I tend to avoid connecting to Github, so I will not be very reactive if you mention me. Don't hesitate to email me directly if you need some info on the code.

Looking back at those last years, I realised that I spent a lot of time with issues that were misconfigurations (most of them being addressed in the doc), questions (generally addressed in the doc) and user-specific un-reproducible bugs (which takes ages and numerous exchanges to deal with). I still think it is important to provide support, but given the situation, I don't think we can afford it. Filtering them out will hopefully alleviate the amount of issues to deal with.

Regarding the future of Elpy, the next step for me is to switch to LSP, it would greatly simplify the code base and make Elpy way easier to maintain. We may loose some functionalities at the moment, but LSP has a lot of traction, and on the long term it should be more robust and offer more features than our current solution. Rethinking the automated test protocol was on my list as well, it has been a nightmare to work with lately... While this would be great, this is stage 2, to look into when Elpy will be in good shape again.

TODO list (for me to deal with)

• [ ] Review the list of active issues (identify issues by order of priority and topic, filter out less important ones)
• [ ] Take a look at the forks to check if some issues have already been addressed (maybe ask @gfederix first ?)
• [ ] Identify issues relevant for the Debian package (with @sten0)
• [ ] Reorganise the tag system to fit new organisation and allow issues dispatching
• [ ] Organise a weekly review to tag and comment new issues/PR

[gfederix]

How about splitting elpy module and python elpy-server into different repositories?

[akshaybadola]

@galaunay I think first thing that can be done is update the README and/or have a pinned issue specifying that there will be a delay in support or maybe even direct them to look at @gfederix's current dev branch which have some fixes.

• Regarding lsp, I've seen it gaining traction myself and tried lsp-mode but found it far too opinionated. The primary advantage would be that backends besides jedi will be immediately available. I prefer elpy because it's python first and is very configurable. How many features and which features will be lost and is it worth the tradeoff?
• Regarding user issues, I felt one thing that this package was missing was detailed logs. User should be able to turn on (sometimes extremely) detailed logging when facing issues as otherwise assisting becomes difficult and they are asked to eval some lisp expressions or other. Those can in fact, be included in some diagnostics module.

[galaunay]

@akshaybadola I updated the readme to reflect the situation, excellent idea.

I had the same feeling about lsp when I tried it a few months ago. Hence my decision at the time to wait for lsp to really "catch up" in terms of features it could provide. I have no idea if it is any better now...

The log idea is a good one. Could also help us... The more complicated part will be to retrieve the RPC errors (running in a python subprocess) through the json RPC protocol. But nothing undoable I think.

@gfederix Do you mean so that we can allow the user to choose between our RPC and lsp ?

[galaunay]

Hi everyone,

I reached for help on reddit to find people that would be interested in helping. I think it is a good time to gather everyone and have a discussion on how to make it work !

Collaborators

Up to date list of the persons that have reached out and were willing to help:

• @nebhrajani-a
• @jeremyheiler
• @akshaybadola
• @sten0 (maintaining the Debian package)
• @rgemulla (willing to keep maintaining elpy-shell.el)
• [email protected] (not sure of his github account name) may be willing to take the lead, but was planning to do some work on python.el as well.

Thanks to all of you. It has been fun to work on Elpy those last years, I hope it will be for you too !

Dealing with the current issues

I know the amount of issues is a bit frightening at the moment, but a lot of them are not critical (or not even issues). Picking one of the latest issue and trying to fix it would already helps a lot. Just mention you are taking care of it in the discussion, so that we are not duplicating the work :).

II think we will need someone to label new issues, and maybe assign them. Is anyone interested ?

Current PRs

I can see there is a few PRs that are waiting to be merged. @rgemulla and @gopar, you are both authorised to merge PRs. do we need to give merging right to a few other people, or will you be able to deal with it ?

Codebase simplification

I tried eglot yesterday. It almost offers all the features that elpy-rpc.el provides. I think it would greatly simplify the work of maintaining Elpy if we could drop the current jedi/black/autopep8/... implementation and rely on a robust LSP implementation like eglot. It will solve a good amount of opened issues in the process...

If anyone is willing to give it a try, It doesn't require to really understand the inner parts of Elpy. You just need to make sure eglot is installed, configured and started with Elpy, and change keybindings accordingly. And of course, delete all the code that will not be necessary anymore...

[nebhrajani-a]

@galaunay: I'm happy to take the lead on some of the current issues and PRs.

I'm slightly busy over the next week, but I can definitely get on Elpy proper starting next weekend. Codebase simplification: while I'm not completely familiar with Elpy's internals, I can give it a try in a few days or collaborate with whoever picks it up.

[gopar]

Hey All,

Deeply sorry about not keeping up w/ elpy.

Current PR's

I can help review PR's. I just slowly started reviewing them again. I will make some time on my calendar for elpy at least once a week. (if we see someone consistently making PR's w/o needing much revisions to them then I'll be more than glad to advocate write permissions for that person :)

Please ping the hell out of me if I don't review your PR's within a week. If I see that I can't keep up, we can revisit giving write permissions. Also might be a good idea for those interested in making PR's to also review other peoples PR. The more eyes the better :)

[rgemulla]

Dear all,

I am still willing to provide input or merge PRs for the elpy-shell component. If there are issues on that part where my input would be helpful, please mention me in the comments so that I get a notice.

Having additional people with rights to merge is a good idea, I think.

[jeremyheiler]

I plan on diving into the elpy codebase over time! I'll work on issues I feel I can investigate.

One of the biggest gaps I've seen as a user of elpy is that the documentation isn't always up to date with the codebase. I plan on looking through that in more detail and submitting PRs to improve it.