c/c <!subteam^S03BGSAUPTQ|@calva-team>

I've switched to this beta (by building the master branch). I'll raise any issues if I come across them 🙂

Isn't there an M1 built nightly? This breaks assumptions in Calva so that M1 users can't use the nightly setting. This is the link Calva will use on an M1/M2 computer using M1/M2 versions of VS Code: https://nightly.link/clojure-lsp/clojure-lsp/workflows/nightly/master/clojure-lsp-native-macos-aarch64.zip

@U0ETXRFEW I think the nightly M1 native is not being properly built, we should fix that indeed c/c @U04V15CAJ, I think we should make that main task build for nightly too or have a different link for nightly arm64 macos

Would be awesome if it could be that link I posted. The logic for selecting binary is a bit complicated as it is. 😃 But if that's trouble on your end, I'd be happy to update Calva.

@U0ETXRFEW really good news, github actions just released support for M1 yesterday https://github.blog/changelog/2022-08-09-github-actions-self-hosted-runners-now-support-apple-m1-hardware/

I'll work on make that work for clojure-lsp to be just like the other builds

Sweet! What a nice timing.

Sorry to spoil the party, but this is only for self-hosted runners. CirrusCI which lsp is currently using is the only thing free public thing I know of that can build it.

Yeah, just read that 😂 https://github.com/actions/runner-images/issues/2187#issuecomment-1209633839

well, I don't think we can make the nightly link to work for the cirrus build, we will need to think on something else so

> well, I don't think we can make the nightly link to work for the cirrus build what is blocking you?

ATM we have https://nightly.link/clojure-lsp/clojure-lsp/workflows/nightly/master/clojure-lsp-native-macos-aarch64.zip, which try to get the artifact from https://github.com/clojure-lsp/clojure-lsp/blob/master/.github/workflows/nightly.yml

Is there a way to have a direct link to the binary cirrus built @U04V15CAJ?

...so? :)

otherwise calva wouldn't be able to download automatically

only manually via #clojure-lsp-builds if we post the cirrus build there

you can upload the binary to Github release manually, like I do with babashka, clj-kondo, etc etc

I think this is also already happening with clojure-lsp

is not a release, it's a master build

You can make a dev snapshot release where you upload it. Every master commit from babashka is uploaded here, including the cirrus one https://github.com/babashka/babashka-dev-builds

hum, I'd like to avoid that, as we are only having this issue for arm64 m1, all other builds are working being stored on github action summary like https://github.com/clojure-lsp/clojure-lsp/actions/runs/2828714594

if cirrus provide just a direct link to the binary like github does, that would work

🤷

I managed to find a link: https://api.cirrus-ci.com/v1/artifact/task/6274753567653888/binaries/clojure-lsp-native-macos-aarch64.zip the issue is that it points to a task run id, it'd be nice if something like latest work

https://github.com/cirruslabs/cirrus-ci-docs/issues/663 it seems

I think I accidentally found a URL that works 😂 https://api.cirrus-ci.com/v1/artifact/github/clojure-lsp/clojure-lsp/main/binaries/clojure-lsp-native-macos-aarch64.zip

Right, we won't have the same link @U0ETXRFEW following nightly standard, but we do have a link for macos arm64 This link: https://api.cirrus-ci.com/v1/artifact/github/clojure-lsp/clojure-lsp/main/binaries/clojure-lsp-native-macos-aarch64.zip

Wait a sec, I have an idea, we could configure a A alias to a sub domain and make it work for all cases following the same standard I guess

That sounds great to me.

Another option might be to have a Github action build that just copies the artifact from cirrus? (Not that I know what I am talking about, but anyway.)

Yeah, I think so, it'd be a little bit tricky to link when cirrus finished then trigger another build on github action or so, but it's an option I guess

The DNS solution is good because it makes things future compatible should providers change.

https://github.com/BetterThanTomorrow/calva/issues/1823

@U0ETXRFEW AFAICS there is no way to make a specific subdomain link to specific URL, only to another domain/subdomain, so if we do that links would still follow different standards, so I guess the only available option for now is use a different link for mac arm64 😢 I'll have to make the same change https://github.com/clojure-lsp/clojure-lsp/blob/master/install, so maybe could be a way to calva use that script instead of manually doing on your side as well?

Do Windows machines have bash?

No, but maybe we should have a install.bat or something? I don't see babashka or clj-kondo doing that though, is there any reason for that @U04V15CAJ?

I don't get why you're not going with the solution I proposed, it seems much simpler.

And also CI-independent

yeah, I was taking a look and it seems would work good enough too

will take a look how babashka does that, thanks

It's working :) https://github.com/clojure-lsp/clojure-lsp-dev-builds/releases Will update nightly link to link to those releases

@U0ETXRFEW Done, you can trust on https://clojurians.slack.com/archives/C032YH7P0R2/p1660153220335399

And to download always the latest you can use: https://github.com/clojure-lsp/clojure-lsp-dev-builds/releases/latest/download/clojure-lsp-native-linux-amd64.zip

🙏 I’ll update the issue.

I consider it a feature, since the goal is to capture all the dependencies (you can use any alias during nix build time) But maybe we could add an option to the CLI to generate a lock file for only certain aliases. In the case of clojure-lsp it's a bit more complex since we have multiple deps.edn files, we need to define the deps.edn and the alias

Are you having issues with nix fetching too many dependencies?

Not really, we just wanted to know if it was possible to exclude some unnecessary deps

Currently the only way is to modify manually the lock file, I'll think about a new option to the deps-lock command to fetch the deps for only one alias

Thanks for the explanation. I’m so new to nix that I don’t know if I’m asking the right questions. The first question I should be asking, I think, is what’s the point of the nix code @ericdallo? Does it provide a dev environment from which you can reproducibly build a clojure-lsp executable? If so, then we need clj-nix to pull in dependencies in the :build alias, and maybe in the :debug alias too. Or is it a runtime environment from which can reproducibly run a clojure-lsp executable? In that case maybe we’d benefit from cutting out the deps from certain aliases. (Or do these questions themselves expose my ignorance? 😅 )

No problem, valid questions! The point is to have a way to build clojure-lsp using nix/flakes, in a pure way, specifying all necessary deps and locking them, with nix we have reliable way to repro the same executable on different envs. So I do think we want clj-nix to use the same aliases we use for prod binary indeed

Yeah, it should be fixed, maybe it's something with babashka.cli project, I can take a look soon

thanks will take a look