search

scalameta / metals-zed

Zed plugin for Metals
Apache License 2.0
45 stars 10 forks source link

The Coursier Metals Requirement #5

Open davesmith00000 opened 4 months ago

davesmith00000 commented 4 months ago

Hi,

If possible, I'd like to understand the requirement to install Metals via Coursier.

I managed to get Zed working with Scala briefly and thought the Metals integration was great! It didn't last long though.

Using Coursier is awkward for me because I tend to use Nix for a lot of tooling set up, and it seems the two don't work well together.

I don't want to get into the details of my exact set up (work machine), I'm just wondering if Coursier does something special that we could replicate via other installation methods? Or if the extension could be made more generally compatible?

Thanks!

SlowBrainDude commented 1 month ago

Things like Coursier are a catastrophe indeed!

Downloading arbitrary binaries from the internet, putting them in random places on the system, and executing them is the number 1 security fuck-up since decades. More or less all security incidents start like that. It was one of the worst ideas ever to download and run setup.exe already 30 years ago, and it still is!

Since people started to do the same bullshit on Linux we start to get all the same malware problems they have on macOS and Windows, where it's since inception "normal" to download and run setup.exe fuck-up.

The problem is the JVM ecosystem. They don't care. They made distributing binaries even core to package management, "just trust me bro" style. And Scala being Scala did adopt all of the worst parts from Java. That's the real issue here.

I hope Scala liberates itself at some point from this insanity.

(Nothing about binary packages as such. They make a great cache. At least in case you have in place proper reproducible builds and a fully transparent build pipeline which starts form source).

tgodzik commented 1 month ago

@davesmith00000 totally missed you message. You should be able to set COURSIER_CACHE per workspace to point to the local workspace (though it will duplicate a lot of jars for a lot of projects) but this would be more in line with how Nix works.

@SlowBrainDude I would try and refrain a bit with the comments, there is plenty of reason why things are working as they are currently and no need to criticise other people's work in this manner.

Building everything from sources and having fully reproducible builds can easily turn into nightmare for people and is not feasible on all possible configurations. Each approach has its issues, though there is no actual security issue here. Jar are not really binaries that can be run on their own, you still need to do that via java. The biggest issue is that caches could break or users might not be fully aware where their artifacts are. Source dependencies would not solve any security problems if users choose to run something themselves.