You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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#33
By moving the repo to a centralized place, I am sure users will be benefited and get less confused.
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.
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-R issue or languageserver issue and do not know where to report the bug for VS Code support for R.
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.
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.
@randy3k That's right, thank you for reminding me.
But since I haven't been involved recently, I felt that approval was necessary.
Now, I just invited him.
@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.
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 Tianjian
@Ikuyadeu I released the v2.1.0 to the marketplace via github actions. It looks like the changes in packages.json does 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?
@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.
Activity
Ikuyadeu commentedon Feb 13, 2019
Sorry, about stopping support.
I am considering just send commit authority to you.
Because the current issues and pull requests are not solved.
randy3k commentedon Feb 13, 2019
If you don’t want to migrate it to REditorSupport, we could also create a fork at REditorSupport and point users to there.
randy3k commentedon Feb 22, 2019
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.randy3k commentedon Jun 3, 2020
@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
ManuelHentschel/vscDebugger#33
By moving the repo to a centralized place, I am sure users will be benefited and get less confused.
randy3k commentedon Jun 3, 2020
By the way, it is impressive to see that @renkun-ken has contributions all around the places.
qinwf commentedon Jun 3, 2020
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:
old introduction:
now
future
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 commentedon Jun 4, 2020
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 commentedon Jun 4, 2020
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.renkun-ken commentedon Jun 4, 2020
@qinwf, Yes, that's the main issue here.
renkun-ken commentedon Jun 4, 2020
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 commentedon Jun 4, 2020
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 commentedon Jun 4, 2020
If possible, I support merging all vscode-R, vscode-r-lsp, and VSCode-R-Debugger together.
Ikuyadeu commentedon Jun 4, 2020
OK, we can do the following steps like Java extension.
Ikuyadeu/r-extension-packtoREditor.Ikuyadeu/vscode-rtoREditor.vscode-lspintovscode-R.VSCode-R-Debuggerintor-extension-pack.@renkun-ken , @andycraig Is It OK?
23 remaining items
randy3k commentedon Jun 14, 2021
@Ikuyadeu Additionally I believe that you'll need to contact Vscode marketplace support to change the publisherId to REditorSupport.
Ikuyadeu commentedon Jun 14, 2021
@randy3k That's right, thank you for reminding me.
But since I haven't been involved recently, I felt that approval was necessary.
Now, I just invited him.
benz0li commentedon Jun 14, 2021
@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.
gvelasq commentedon Jun 14, 2021
@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.
Ikuyadeu commentedon Jul 1, 2021
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.
randy3k commentedon Jul 1, 2021
Thanks @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).
renkun-ken commentedon Jul 1, 2021
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.
renkun-ken commentedon Jul 1, 2021
I'll raise separate issues to track post-migration issues such as change publishId and integrate vscode-r-lsp into vscode-R.
renkun-ken commentedon Jul 20, 2021
@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?
Ikuyadeu commentedon Jul 20, 2021
@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?
renkun-ken commentedon Jul 29, 2021
I think the reason is enough. It is now maintained by REditorSupport and it is thus reasonable to use it as the publisher.
Ikuyadeu commentedon Jul 29, 2021
@renkun-ken Thannk you, I'll send an email to the marketplace, and add cc your outlook address.
Ikuyadeu commentedon Jul 29, 2021
@renkun-ken I submit the issue on microsoft/vsmarketplace#133
Please check here.
renkun-ken commentedon Jul 29, 2021
Thanks for raising the issue!