Repository navigation
Migrating to REditorSupport #98
Description
Activity
Sorry, about stopping support.
I am considering just send commit authority to you.
Because the current issues and pull requests are not solved.Reacted by Riley RoachIf you don’t want to migrate it to REditorSupport, we could also create a fork at REditorSupport and point users to there.
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
publishertoREditorSupport.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
ManuelHentschel/vscDebugger#33By moving the repo to a centralized place, I am sure users will be benefited and get less confused.
By the way, it is impressive to see that @renkun-ken has contributions all around the places.
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
languageserverR 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:
- VSCode
+ vscode-R + vscode-r-lsp + languageserver - VSCode R Langauage Support
- VSCode - vscode-R + vscode-r-lsp VSCode R Langauage Support
- 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.
- VSCode
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.
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-Rissue orlanguageserverissue and do not know where to report the bug for VS Code support for R.Reacted by Gustavo Velásquez@qinwf, Yes, that's the main issue here.
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.
If possible, I support merging all vscode-R, vscode-r-lsp, and VSCode-R-Debugger together.
Reacted by Adam Altmejd and Gustavo VelásquezOK, we can do the following steps like Java extension.
- Move
Ikuyadeu/r-extension-packtoREditor. - Move
Ikuyadeu/vscode-rtoREditor. - Integrate
vscode-lspintovscode-R. - Add
VSCode-R-Debuggerintor-extension-pack.
@renkun-ken , @andycraig Is It OK?
Reacted by Randy Lai, Kun Ren, Andrew Craig, Jacob Wujciak-Jens, Adam Altmejd, Gustavo Velásquez and Tianjian- Move
23 remaining items
@Ikuyadeu When moving this repository to the REditorSupport organization, please make sure that the R extension is sill allowed to be published on OpenVSX in the future.
Don Jayamanne's Python extension has been stuck at version 2020.10.332292344 on OpenVSX for months due to its dependency on the Jupyter extension and the runtime license¹ of the latter.
ℹ️ ¹This issue has only been resolved recently by microsoft/vscode-jupyter#5812, which may allow updating both Python and Jupyter extensions on OpenVSX.This is important for all users of VSCodium, Eclipse Theia and code-server.
@benz0li, thank you for raising this here. There is an open issue re: verifying this extension in the OpenVSX registry: #524
The good news is that REditorSupport/vscode-r-lsp#55 is already verified here.
Thank you as well for the update on microsoft/vscode-jupyter#5812. The Jupyter data viewer is one of several solutions being considered in #506, so it's good to see the MIT license.
Now, I move the vscode-r to the REditor.
In the vscode discussion, I cannot rename the Marketplace owner for current user experience as same as ESLint and TSLint.
However, we can publish this extension via GitHub Actions.I will only rename the GitHub owner and contents of the LICENCE file to REditor at a later date.
Reacted by Kun Ren, eitsupi, Gustavo Velásquez, Manuel Hentschel and TianjianThanks @Ikuyadeu for initiating the work. Awesome.
I believe that you could contact Microsoft marketplace support to change the publishId. Smilar to what we have done before for https://github.com/REditorSupport/vscode-r-lsp (moved from your name to REditorSupport REditorSupport/vscode-r-lsp@0053bfd).
Looks like there are plentiful examples where publishId is changed (e.g. microsoft/vscode#3670). There are also examples of quite popular projects (e.g. prettier/prettier-vscode#41, prettier/prettier#2577). I guess if we are to change it, the earlier, the better.
We could update README to notify what should be done on the user side.
I'll raise separate issues to track post-migration issues such as change publishId and integrate vscode-r-lsp into vscode-R.
Reacted by Randy Lai and Gustavo Velásquez@Ikuyadeu I released the
v2.1.0to the marketplace via github actions. It looks like the changes inpackages.jsondoes not have effect on the publisher name on the marketplace webpage.Would you like to take a look and see if there are some places to update the publisher name?
Reacted by Yuki Ueda@renkun-ken Thank you for releasing.
It means all of the members can publish our extension at any time.Looking at the previous discussion, I didn't send an email to vscode team because I thought it could be reflected without changing the publisher.
OK, I will send you an email again. I will write "I'm going to remove my name because other members mainly maintain it".
Should I write another motivation to change the publisher?OK, I will send you an email again. I will write "I'm going to remove my name because other members mainly maintain it".
Should I write another motivation to change the publisher?I think the reason is enough. It is now maintained by REditorSupport and it is thus reasonable to use it as the publisher.
Reacted by Yuki Ueda@renkun-ken Thannk you, I'll send an email to the marketplace, and add cc your outlook address.
@renkun-ken I submit the issue on microsoft/vsmarketplace#133
Please check here.Reacted by Kun RenThanks for raising the issue!
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.