Honnix

Maybe it is better to use the resolved runtime toolchain `ctx.toolchains["@bazel_tools//tools/jdk:runtime_toolchain_type"].java_runtime` ? As commented in https://github.com/bazelbuild/rules_jvm_external/issues/445#issuecomment-674437363, the embedded jdk may not be suitable.

> Maybe it is better to use the resolved runtime toolchain `ctx.toolchains["@bazel_tools//tools/jdk:runtime_toolchain_type"].java_runtime` ? > > As commented in [#445 (comment)](https://github.com/bazelbuild/rules_jvm_external/issues/445#issuecomment-674437363), the embedded jdk may not be suitable. NVM this seems...

I think it was [this line](https://github.com/bazelbuild/rules_jvm_external/commit/3ec0bbb95278bf01f4d3e19b6c193d61e79ffc19#diff-c8bacb964b6cf475b85b8fa254a2769dcf34f28b813437048f877aa3ffa3d71bR93) resulted in generating a wrong `http_file` target. https://repo1.maven.org/maven2/com/google/guava/listenablefuture/9999.0-empty-to-avoid-conflict-with-guava/ is by design not to have source jar, so ideally `rules_jvm_external` should better handle this type...

I believe https://github.com/bazelbuild/rules_jvm_external/pull/1137 should be able to help. You can pass `--parallel 64` from `maven_install` to coursier.

Sorry for replying back. I understand why this is not a recommended deployment model, but in practice, it is not always feasible to have a flytepropeller running in a k8s...

I believe this is still a very relevant feature request.

Looks like this is also unmaintained. Have you considered forking it into https://github.com/python-lsp ? @haplo

Ah, thanks. I didn't know this fork.

> piptools/scripts/types.py:6:1: F401 'typing.Optional' imported but unused ~~Not exactly sure of this failure.~~ Nvm

Converted to a draft as it is not ready due to failing checks and missing tests.