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

When installing ltex-ls it won't fetch the jdk* folder which has the java binaries #1531

Closed
3 tasks done
v3natio opened this issue Oct 20, 2023 · 8 comments
Closed
3 tasks done

Comments

@v3natio
Copy link

v3natio commented Oct 20, 2023

I've searched open issues for similar requests

  • Yes

I've manually reviewed logs to find potential errors

  • Yes

I've recently downloaded the latest plugin version of mason.nvim

  • Yes

Problem description

When installing ltex-ls LaTeX LSP through Mason, it won't retain the jdk-{version} folder, which contains the java binaries necessary for it to run.

Right now, this is what Mason is fetching:

...
"source": {
  "id": "pkg:github/valentjn/[email protected]",
  "asset": [
    {
      "target": "unix",
      "file": "ltex-ls-{{version}}.tar.gz",
      "bin": {
        "lsp": "ltex-ls-{{version}}/bin/ltex-ls",
        "cli": "ltex-ls-{{version}}/bin/ltex-cli"
      }
    },
...

It's downloading the entire tarball, but then it'll only retain the bin and lib folders. ltex-ls advertises that "[it] comes with everything included, no need to install Java or LanguageTool." Therefore, this behavior from Mason goes against the upstream package, as it requires the user to manually install/compile their own java binaries, and include them in the runtime path.

Expected behavior

In order to fix this issue, Mason would have to retain the jdk-{version} folder, which is already included in the tarball. And, it'd also need to create a symlink for the java binaries to be included in the ./mason/bin/ (as it's the one included in the runtime path) directory, so they'll be readable by ltex-ls.

Steps to reproduce

Simply install ltex-ls and try running it on a .tex file, it'll exit with error code 1 and signal 0 (check the first screenshot). I've also attached a screenshot (second one) of :LspInfo.

Affected packages

ltex-ls

Neovim version (>= 0.7)

NVIM v0.9.4
Build type: Release
LuaJIT 2.1.1696795921

system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Operating system/version

Linux halo 6.5.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 10 Oct 2023 21:10:21 +0000 x86_64 GNU/Linux

Healthcheck

==============================================================================
mason: require("mason.health").check()

mason.nvim ~
- OK mason.nvim version v1.8.1
- OK PATH: prepend
- OK Providers: 
  mason.providers.registry-api
  mason.providers.client
- OK neovim version >= 0.7.0

mason.nvim [Registries] ~
- OK Registry `github.com/mason-org/mason-registry version: 2023-10-20-beefy-forest` is installed.

mason.nvim [Core utils] ~
- OK unzip: `UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send`
- OK wget: `GNU Wget 1.21.4 built on linux-gnu.`
- OK curl: `curl 8.4.0 (x86_64-pc-linux-gnu) libcurl/8.4.0 OpenSSL/3.1.3 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.4) libssh2/1.11.0 nghttp2/1.57.0`
- OK gzip: `gzip 1.13`
- OK tar: `tar (GNU tar) 1.35`
- OK bash: `GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)`
- OK sh: `Ok`

mason.nvim [Languages] ~
- WARNING Go: not available
  - ADVICE:
    - spawn: go failed with exit code - and signal -. go is not executable
- WARNING Composer: not available
  - ADVICE:
    - spawn: composer failed with exit code - and signal -. composer is not executable
- WARNING PHP: not available
  - ADVICE:
    - spawn: php failed with exit code - and signal -. php is not executable
- WARNING cargo: not available
  - ADVICE:
    - spawn: cargo failed with exit code - and signal -. cargo is not executable
- WARNING luarocks: not available
  - ADVICE:
    - spawn: luarocks failed with exit code - and signal -. luarocks is not executable
- WARNING javac: not available
  - ADVICE:
    - spawn: javac failed with exit code - and signal -. javac is not executable
- WARNING java: not available
  - ADVICE:
    - spawn: java failed with exit code - and signal -. java is not executable
- WARNING julia: not available
  - ADVICE:
    - spawn: julia failed with exit code - and signal -. julia is not executable
- WARNING Ruby: not available
  - ADVICE:
    - spawn: ruby failed with exit code - and signal -. ruby is not executable
- WARNING RubyGem: not available
  - ADVICE:
    - spawn: gem failed with exit code - and signal -. gem is not executable
- OK python: `Python 3.11.5`
- WARNING pip: not available
  - ADVICE:
    - spawn: python3 failed with exit code 1 and signal 0. /usr/bin/python3: No module named pip

- OK node: `v20.8.1`
- OK python venv: `Ok`
- OK npm: `10.2.1`

mason.nvim [GitHub] ~
- OK GitHub API rate limit. Used: 1. Remaining: 59. Limit: 60. Reset: Fri 20 Oct 2023 07:33:51 PM CEST.
  Install and authenticate via gh-cli to increase rate limit.

Screenshots or recordings

image
image

@chrisgrieser
Copy link

I can confirm the issue. It's tricky, the LSP simply does not work, and only after going through :LspLog the underlying issue becomes apparent, making it hard for beginners to figure out what the issue is when their LSP does not work.

[ERROR][2023-11-04 16:55:02] .../vim/lsp/rpc.lua:734	"rpc"	"/Users/chrisgrieser/.local/share/nvim/mason/bin/ltex-ls"	"stderr"	"The operation couldn’t be completed. Unable to locate a Java Runtime.\nPlease visit http://www.java.com for information on installing Java.\n\nThe operation couldn’t be completed. Unable to locate a Java Runtime.\nPlease visit http://www.java.com for information on installing Java.\n\n"

@v3natio
Copy link
Author

v3natio commented Nov 4, 2023

Yeah, right now it isn't such a bother for me, I've got the jdk binaries installed in the meantime. But the ideal scenario is for them to be fetched and included in the runtime, as they're already packaged in the tarball.

Plus the change isn't complicated at all, I ran a local copy of Mason and just modified the fetch instructions in the json, then symlinked the jdk binary when I was going over this issue.

@DrewAlderfer
Copy link

I've been having this same issue. The language server is released with OS specific packages which include the java dependencies, and a version that requires a local installation of Java. The way I solve it is to just download the os specific binary from the releases section of the github repo and overwrite the one mason is grabbing.

Is there a way to direct mason to the correct version of a release through the config? I looked into this a bit a few weeks ago when I first encountered the problem, but it seemed like there was no way to tell Mason to prefer the os specific download.

@chrisgrieser
Copy link

Ok, so I looked into it, and the root cause is these lines in the mason-registry repo:
https://github.com/chrisgrieser/mason-registry/blob/main/packages/ltex-ls/package.yaml#L17-L34

it only lists the ltex-cli and lsp, but not the jdk bundled with it. Including the bundled jdk should be a matter of adding to that package specification. Unfortunately, I do not really know anything about Java, so I am not really certain files exactly need to be included. Maybe someone who knows that could make a PR adding the required files to the package specification?

@williamboman
Copy link
Owner

This has been brought up a couple of times and my stance on it is this. At this point I wouldn't mind changing it as it seems to be a reoccurring topic.

@v3natio
Copy link
Author

v3natio commented Dec 8, 2023

This has been brought up a couple of times and my stance on it is this. At this point I wouldn't mind changing it as it seems to be a reoccurring topic.

But, due to the way the runtime path is read, wouldn't vendoring the jdk binary not cause any issues? Correct me if I'm wrong, but if there's a system jdk then that'll supersede the vendored binary.

@chrisgrieser
Copy link

chrisgrieser commented Jan 27, 2024

edit: the PR has been merged, making all the instructions below obsolete. Just uninstall and install via mason, wait for the download to finish (might take a bit, because the bundled JRE is a bit bigger), and ltex should work fine without any need for you to do anything further anymore 🥳


I made a PR fixing the issue on mac and windows: mason-org/mason-registry#4311

You can already use the fix before the PR is merged by adding the fork as registry in your mason settings:

require("mason").setup {
	registries = {
		"github:chrisgrieser/mason-registry", -- only has ltex-fix
		"github:mason-org/mason-registry",
	},
}
})

Restart nvim for the registry change to take effect. Then, run :MasonUninstall ltex-ls and :MasonInstall ltex-ls to re-install ltex, the java runtime should now be included in the installation. No more need to install a JRE for ltex to work.


What remains with the PR is the minor issue that ltex is not able to automatically find the java runtime. I suspect this is due to mason symlinking binaries. However, this one can be easily fixed by setting JAVA_HOME in your config:

require("lspconfig").ltex_ls.setup({
	-- settings = {} -- your settings
	on_attach = function ()
		vim.env.JAVA_HOME = vim.fs.find(
			function(name) return vim.startswith(name, "jdk-") end,
			{ path = vim.fn.stdpath("data") .. "/mason/packages/ltex-ls/", type = "directory" }
		)[1]
	end
})

(The path is retrieved dynamically, since the exact path changes with ltex releases. I use JAVA_HOME instead of the ltex-setting ltex.java.path, since the latter does not appear to work for me.)

@williamboman
Copy link
Owner

I believe this can be closed with mason-org/mason-registry#4311. Do note my comment here though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Closed
Development

No branches or pull requests

4 participants