search

bscan / PerlNavigator

Perl Language Server that includes syntax checking, perl critic, and code navigation
MIT License
198 stars 39 forks source link

Attempted to run perlimports lint: Error: Command failed #48

Closed blingenau closed 1 year ago

blingenau commented 1 year ago

Hey. Get this error often. Sometimes disabling and reenabling the extension fixes it, sometimes it doesn't.

Attempted to run perlimports lint: Error: Command failed: perl /home/blingenau/.vscode-server/extensions/bscan.perlnavigator-0.3.1/server/src/perl/perlimportsWrapper.pl --lint --json --filename <path_to_file>
bscan commented 1 year ago

Hi @blingenau, this is to support perlimports, a recently added feature. It will attempt to run perlimports, but should not impact any other functionality if the command does not work. I will improve the logging to be more clear. The most likely cause is that you don't have the latest version of perlimports and it fails during the require. Is any other functionality impacted by this, or is it simply adding the message to the logs?

Similarly, if you run "Format Document", it should still work and format exclusively with Perl::Tidy and not perlimports. The logging is better on that command though.

If you want to clear the error message, you can either install perlimports from cpan or set perlnavigator.perlimportsLintEnabled to false.

oalders commented 1 year ago

I think it would be fine to disable perlimports linting and formatting by default. I had meant to do this in the original PR.

blingenau commented 1 year ago

I could be wrong but I had some issues with command clicking named imports, not sure if it was related to this error though

bscan commented 1 year ago

I think it's a good workflow when something seems broken to open the log and looks for errors. For perlimports tidy, I had modified the log to say Attempted to run perlimports tidy Unable to run perlimports as it is not installed, which seems much more gentle than erroring. However, I forgot to do the same modification for perlimports lint.

I'm also very interested in any issues related to the go-to-definition of imports. Generally speaking, the go-to-definitions should be highly accurate. The primary limitations are on "require'd" imports, or when the file can't compile (tab marked red). My solutions for those are to prioritize fixing compilation problems and prefer "use" over "require". However, if you see any other issues with go-to-definition, definitely let me know. @blingenau, I believe this ticket was filed by a colleague of yours https://github.com/bscan/PerlNavigator/issues/13. Although that specific has been fixed, there could be other lingering issues/limits with massive codebases.

blingenau commented 1 year ago

Makes sense to me, I'll keep an eye out if the issue pops up again. I'll close the issue for now

bscan commented 1 year ago

I updated the defaults to not run perlimports. For people without perlimports installed, this should save some resources by reducing the number of subprocesses created. I also fixed the issue where the messages from perlImportsWrapper were not being displayed in the log. Thanks @blingenau for the issue. Let me know if anything else doesn't work as expected. (Although I haven't pushed these changes to vscode yet)