Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No tests discovered #194

Open
P4Cu opened this issue Mar 18, 2022 · 5 comments
Open

No tests discovered #194

P4Cu opened this issue Mar 18, 2022 · 5 comments

Comments

@P4Cu
Copy link

P4Cu commented Mar 18, 2022

I've a case which is very similar to #94 as package from Codium (0.11.1) fails but on Microsoft (0.11.0) works.

[2022-03-18 22:08:32.339] [exthost] [info] Extension host with pid 21789 exiting with code 0
[2022-03-18 22:08:34.311] [exthost] [info] Extension host with pid 22009 started
[2022-03-18 22:08:34.311] [exthost] [info] Skipping acquiring lock for /home/p4c/.config/VSCodium/User/workspaceStorage/0743c48de7deffab257393a8bb62fb54.
[2022-03-18 22:08:34.472] [exthost] [info] ExtensionService#_doActivateExtension matklad.rust-analyzer, startup: false, activationEvent: 'onLanguage:rust'
[2022-03-18 22:08:34.497] [exthost] [info] ExtensionService#_doActivateExtension vscode.debug-auto-launch, startup: true, activationEvent: '*'
[2022-03-18 22:08:34.499] [exthost] [info] ExtensionService#_doActivateExtension vscode.git-base, startup: true, activationEvent: '*', root cause: vscode.github
[2022-03-18 22:08:34.500] [exthost] [info] ExtensionService#_doActivateExtension vscode.ipynb, startup: true, activationEvent: '*'
[2022-03-18 22:08:34.503] [exthost] [info] ExtensionService#_doActivateExtension alefragnani.project-manager, startup: true, activationEvent: '*'
[2022-03-18 22:08:34.509] [exthost] [info] ExtensionService#_doActivateExtension ms-vscode.test-adapter-converter, startup: true, activationEvent: '*', root cause: hbenl.vscode-test-explorer
[2022-03-18 22:08:34.512] [exthost] [info] ExtensionService#_doActivateExtension vscodevim.vim, startup: true, activationEvent: '*'
[2022-03-18 22:08:34.919] [exthost] [info] ExtensionService#_doActivateExtension vscode.git, startup: true, activationEvent: '*'
[2022-03-18 22:08:34.933] [exthost] [info] ExtensionService#_doActivateExtension vscode.github, startup: true, activationEvent: '*'
[2022-03-18 22:08:34.936] [exthost] [info] ExtensionService#_doActivateExtension hbenl.vscode-test-explorer, startup: true, activationEvent: '*', root cause: Swellaby.vscode-rust-test-adapter
[2022-03-18 22:08:35.028] [exthost] [info] ExtensionService#_doActivateExtension Swellaby.vscode-rust-test-adapter, startup: true, activationEvent: '*'
[2022-03-18 22:08:35.044] [exthost] [error] Activating extension Swellaby.vscode-rust-test-adapter failed due to an error:
[2022-03-18 22:08:35.044] [exthost] [error] Error: Cannot find module '/home/p4c/.vscode-oss/extensions/swellaby.vscode-rust-test-adapter-0.11.1/src/main.js'
Require stack:
- /usr/share/codium/resources/app/out/vs/loader.js
- /usr/share/codium/resources/app/out/bootstrap-amd.js
- /usr/share/codium/resources/app/out/bootstrap-fork.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:887:15)
    at Module._load (internal/modules/cjs/loader.js:732:27)
    at Function.f._load (electron/js2c/asar_bundle.js:5:12913)
    at Function.n._load (/usr/share/codium/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:104:32147)
    at Function.S._load (/usr/share/codium/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:104:28736)
    at Function.g._load (/usr/share/codium/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:99:60371)
    at Module.require (internal/modules/cjs/loader.js:959:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Function.r [as __$__nodeRequire] (/usr/share/codium/resources/app/out/vs/loader.js:5:101)
    at d._loadCommonJSModule (/usr/share/codium/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:104:30306)
    at d._doActivateExtension (/usr/share/codium/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:90:13385)
    at d._activateExtension (/usr/share/codium/resources/app/out/vs/workbench/api/node/extensionHostProcess.js:90:12327)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Promise.all (index 0)
    at async Promise.all (index 0)
[2022-03-18 22:08:35.122] [exthost] [info] Eager extensions activated
[2022-03-18 22:08:35.139] [exthost] [info] ExtensionService#_doActivateExtension vscode.emmet, startup: false, activationEvent: 'onStartupFinished'
[2022-03-18 22:08:35.150] [exthost] [info] ExtensionService#_doActivateExtension vscode.merge-conflict, startup: false, activationEvent: 'onStartupFinished'
[2022-03-18 22:08:35.152] [exthost] [info] ExtensionService#_doActivateExtension eamodio.gitlens, startup: false, activationEvent: 'onStartupFinished'
[2022-03-18 22:08:35.184] [exthost] [info] ExtensionService#_doActivateExtension vadimcn.vscode-lldb, startup: false, activationEvent: 'onStartupFinished'

And here's the folder view:

/home/p4c/.vscode-oss/extensions/swellaby.vscode-rust-test-adapter-0.11.1
images  LICENSE.txt  node_modules  package.json  README.md
@P4Cu
Copy link
Author

P4Cu commented Mar 18, 2022

Well I think it's really a duplicate @calebcartwright,

@calebcartwright
Copy link
Member

Well I think it's really a duplicate @calebcartwright,

Thank you for reiterating your perspective, though I was already aware you felt this way given the other thread. For context, the root cause of the prior issue was strictly related to OpenVSX's approach to how they package extensions which aren't directly published to their registry. I had originally intended to get access to publish directly to their registry, but they require too many accounts with too much access to those accounts for my comfort level. As such the resolution of the prior issue was actually on the OpenVSX side in open-vsx/publish-extensions#478

Unfortunately, it seems the OpenVSX team decided to once again change their approach not long after that fix (ostensibly in open-vsx/publish-extensions#494). This has resulted in a similar end result, but a different root cause that will need its own resolution.

This separate root cause needing a separate resolution, in conjunction with not wanting to continue dialog/investigating on a closed issue, is why I asked for a new issue and I appreciate you opening this.

As to the latest issue, I'm not sure why their process is broken again. They are clearly not reusing the maintainer-authored VSIXs from the source repository nor the VS Code Marketplace, and I couldn't tell you why they are once again invalidly packaging from source. To be fully transparent, I've found the OpenVSX process surprisingly cumbersome from the get go, and I don't have the bandwidth right now to try to troubleshoot someone else's incorrect packaging of our source.

You may want to engage with them to see what's going on, or you may just find it easier to grab the VSIX we provide

@P4Cu
Copy link
Author

P4Cu commented Mar 19, 2022

Whoa man! Better support than most of paid products :D
I believe most of codium folks don't mind installing extensions either from MS store or directly from github releases but there's one thing that could be done.
Open-vsx should not publish extensions if they cannot make it working. So they should simply take down your extension to not confuse anyone.

@calebcartwright
Copy link
Member

Open-vsx should not publish extensions if they cannot make it working. So they should simply take down your extension to not confuse anyone.

I appreciate and support their vision, but I do wish they could improve the execution to make things more straightforward for publishers. They understandable have a method through which extensions can get on their registry independent of anyone (think about cases where maintainers have vanished), but I personally think they rely on that model too much/as the default instead of first trying to collaborate with publishers.

I did discuss the remove-from-registry option with them the last go around, but thought it would be better to just fix what was out there. I'd still prefer to have this extension available directly in Open VSX, but just not sure what all has changed again. In any case, something will have to change on the registry, so whenever I get some extra cycles to take a closer look the determination will really be between whether it's possible to fix the new issue or just remove altogether, but I won't know which until I get in there.

@Cypher1
Copy link

Cypher1 commented Oct 26, 2022

Ahh, thank you! The VSIX File worked like a charm!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants