Vscode-r: Migrating to REditorSupport

[randy3k]

It’s pity that you are no longer supporting it. Are you interested in moving it to REditorSuport?

I will see what can be done with the lsp and this package.

[Ikuyadeu]

Sorry, about stopping support.
I am considering just send commit authority to you.
Because the current issues and pull requests are not solved.

[randy3k]

If you don’t want to migrate it to REditorSupport, we could also create a fork at REditorSupport and point users to there.

[randy3k]

I am writing to see your decision on migrating the repo to REditorSupport. You are already an owner of REditorSupport, so you should be able to transfer it if you want to. On top of that, you may also need to contact Microsoft to change the publisher to REditorSupport.

[randy3k]

@Ikuyadeu

I just want to reinitiate the discussion on migrating the repo to REditorSupport.
A similar issue was created for the debugger related packages developed by @ManuelHentschel
https://github.com/ManuelHentschel/vscDebugger/issues/33

By moving the repo to a centralized place, I am sure users will be benefited and get less confused.

[randy3k]

By the way, it is impressive to see that @renkun-ken has contributions all around the places.

[qinwf]

Unified VS Code R plugin will provide a much better experience.

You do not need to teach the new users to install A and then B and the C.

Just get one Plugin and then it will automatically download the languageserver R package for you to get all the functionality going. That's it. It is simple.

I simplified some descriptions about how to set up R with VS Code before.

For example:

old introduction:

• VSCode + vscode-R + vscode-r-lsp + languageserver - VSCode R Langauage Support

now

• VSCode - vscode-R + vscode-r-lsp VSCode R Langauage Support

future

• VSCode - VSCode R Langauage Support

People are lazy. If there is an easy way to get things done, it will be much easier for them to adopt new technology.

[renkun-ken]

As VSCode-R-Debugger and httpgd are working better, my recommended tools of VSCode R support will become the following:

VSCode + vscode-R + vscode-r-lsp + languageserver + radian + VSCode-R-Debugger + vscDebugger + httpgd.

I can already feel the confusion from the future users.

However, combining them into much fewer projects may not look necessary to me. I think if the VSCode extensions could install their external R package dependencies automatically, e.g. vscode-r-lsp installs languageserver automatically, VSCode-R-Debugger installs vscDebugger automatically. Then a VSCode R Extension Pack could make it much simpler.

[qinwf]

If there are many plugins, it will be harder for users to do bug reports.

Some users in the past talked about they do not know if a issue is a vscode-R issue or languageserver issue and do not know where to report the bug for VS Code support for R.

[renkun-ken]

@qinwf, Yes, that's the main issue here.

[renkun-ken]

Sometimes, however, we are not sure where to put a certain issue. For example, it might first appear to be a bug in radian, but turns out to be a bug in vscode-R sending code to radian. But there's no point to combine radian and vscode-R.

But if it is only for bug reporting confusion, I think we could make a central place for all bug reporting if user is not sure where to put it.

[randy3k]

By the way, I fully support merging vscode-R and vscode-r-lsp. Originally I approached @Ikuyadeu to see they wants to add support of languageserver but for some reasons, they created a new project rather than adding the feature to vscode-R.

[renkun-ken]

If possible, I support merging all vscode-R, vscode-r-lsp, and VSCode-R-Debugger together.

[Ikuyadeu]

OK, we can do the following steps like Java extension.

1. Move Ikuyadeu/r-extension-pack to REditor.
2. Move Ikuyadeu/vscode-r to REditor.
3. Integrate vscode-lsp into vscode-R.
4. Add VSCode-R-Debugger into r-extension-pack.

@renkun-ken , @andycraig Is It OK?

[renkun-ken]

@Ikuyadeu Sounds good to me.

VSCode-R-Debugger is still at an early stage, very experimental, and not published to vscode marketplace yet. When it is published at some point, we could put it into r-extension-pack.

@ManuelHentschel do you think if makes sense to integrate the R debugger with vscode-R at some point? We already have a lot of confusion going on here.

[randy3k]

Do we also want to change the publishId of vscode-R and r-extension-pack? As far as I understand, if we change the publishId to REditorSupport, existing users won't be able to update vscode-R automatically. Of course, having them under REditorSupport will be less confusing for future users. (I am open to this).

Maybe better to suffer now than regret in the future.

[Ikuyadeu]

I don't think it makes much sense to change the publisher.
GitHub's authority movement function changes old repository links to new repository link shortcuts.
Moreover, the change of the link of the repository and the issue described in package.json leads the user to the new repository and the issue.

[randy3k]

There is also an administrative consideration. With the current publishId, @Ikuyadeu is the only person who has control of the releases.

In my opinion, I think it is better to have a least two admins taking charge of the package. (I don't mean @Ikuyadeu is not doing your job adequately, nor I am trying to take away the credits from @Ikuyadeu). From a management perspective, it is always good to have a backup plan. That's also why I have invited @renkun-ken to REditorSupport. In case, I am out of town or for whatever reasons not able to reply, there is always another person to do the job. (It also reminds myself that I should add @renkun-ken as a maintainer of languageserver).

[randy3k]

Sadly, CRAN only allows one maintainer.

Invalid DESCRIPTION:
Authors@R field gives more than one person with maintainer role:
  Randy Lai <[email protected]> [aut, cre]
  Kun Ren <[email protected]> [aut, cre]

[Ikuyadeu]

So, how are these fixed works?

Quick work

• Move Ikuyadeu/r-extension-pack repo to REditor.
• Move Ikuyadeu/vscode-r repo to REditor.

Early-stage work

• Add vscode-lsp as the vscode-R dependencies

Feature work (Looks large works)

• Integrate vscode-lsp into vscode-R and remove from dependencies

If VSCode-R-Debugger will be published

• Add VSCode-R-Debugger into r-extension-pack

If @Ikuyadeu stoped to replying the new version request

• Publish insider version r-extension-pack and vscode-r as the new publisher

[renkun-ken]

I think integrating vscode-r-lsp into vscode-r is fairly easy. I'm interested in putting the two together quickly if nobody is more interested?

[randy3k]

@Ikuyadeu Thank you. I agree that moving r-extension-pack and vscode-r can be done immediately, especially you have already write permission to the org.

If @Ikuyadeu stoped to replying the new version request
Publish insider version r-extension-pack and vscode-r as the new publisher

Ha, but I guess we'll need your approval in order to change the publishId. Not sure how we could approach you if you were not replying...

@renkun-ken please work on the integration. By the way, there is always one thing that I notice, the title in settings in "r" instead of the convention "R". I always wanted to submit a PR to fix it. Perhaps you could fix it while working on the merge.

[ManuelHentschel]

VSCode-R-Debugger is still at an early stage, very experimental, and not published to vscode marketplace yet. When it is published at some point, we could put it into r-extension-pack.

@ManuelHentschel do you think if makes sense to integrate the R debugger with vscode-R at some point? We already have a lot of confusion going on here.

Once the debugger is as stable as vscode-R, I think this would make sense, since the two extensions don't really have any conflicting overlap and users would profit from having everything inside one extension.

[Ikuyadeu]

Ha, but I guess we'll need your approval in order to change the publishId. Not sure how we could approach you if you were not replying...

My email address is on my profile.
Also, unlike last year, I continue to work on checking really bad code, and continue to publish a new version once a month when features are added to the extension.

I agree that extension integration benefits both users and extension developers like us.

However, I feel that revoking the copyright has no benefit to me or the user after the integration.
Because I have already passed the commit privilege to the key collaborators.
And issues will gather to the vscode-r instead of vscode-r-lsp. If the issues are caused by original lsp, we can just address the REditor/language-server

[renkun-ken]

@Ikuyadeu @randy3k

I've done the integration of the language client from vscode-r-lsp at https://github.com/renkun-ken/vscode-R/tree/lsp and it works quite well. Looking forward to the migration to REditorSupport and then I could send a PR.

It's obvious that the two codebases have own licenses and copyright. I'm not sure if there's anything I should do to reflect that, merging the licenses or add some statement somewhere?

[randy3k]

My email address is on my profile.

Also, unlike last year, I continue to work on checking really bad code, and continue to publish a new version once a month when features are added to the extension.

I think you still miss the point of having an alternative admin. I don’t mean that you are not replying intentionally or going to abandon the package without notice. Just touch wood, there is a possibility that you get sick and become so ill to reply. You shouldn’t think of transferring the publishId as revoking copyright. You are still the admin who are in charge of the package and you still own the copyright. With that said, I respect your decision on this matter.

@renkun-ken to make thing simpler, I am ok to revoke the copyright of vscode-r-lsp. So just copy my code to viscose-R.

Thank you in advance for merging the project.

[assignUser]

@Ikuyadeu @renkun-ken I would like to refresh this discussion in view of #405 . As renkun-ken has already done the job of integrating vscode-lsp into vscode-R the move should be pretty straight forward?