never did that, but I feel like it's missing the concept of project to know other css files

Sounds likely!

If e.g. hover a symbol reset! in the script. I get a very bare bones and boring hover. The lsp message log looks like so:

[Trace - 12 :02:43 PM] Sending request 'textDocument/hover - (32)'.
Params: {
    "textDocument": {
        "uri": "file:///Users/pez/.config/joyride/scripts/js_repl.cljs"
    },
    "position": {
        "line": 54,
        "character": 13
    }
}


[Trace - 12:02:43 PM] Received response 'textDocument/hover - (32)' in 12ms.
Result: {
    "range": {
        "start": {
            "line": 54,
            "character": 12
        },
        "end": {
            "line": 54,
            "character": 18
        }
    },
    "contents": {
        "kind": "markdown",
        "value": "

\n\n----\n\n*[/Users/pez/.config/joyride/scripts/js_repl.cljs](file:///Users/pez/.config/joyride/scripts/js_repl.cljs)*"
    }
}

[Trace - 12:03:15 PM] Sending request 'textDocument/hover - (36)'.
Params: {
    "textDocument": {
        "uri": "file:///Users/pez/.config/joyride/scripts/js_repl.clj"
    },
    "position": {
        "line": 54,
        "character": 12
    }
}


[Trace - 12:03:15 PM] Received response 'textDocument/hover - (36)' in 13ms.
Result: {
    "range": {
        "start": {
            "line": 54,
            "character": 12
        },
        "end": {
            "line": 54,
            "character": 18
        }
    },
    "contents": {
        "kind": "markdown",
        "value": "

\n\nSets the value of atom to newval without regard for the\ncurrent value. Returns newval.\n\n__Examples:__\n\n

\n\n__See also:__\n\n[clojure.core/swap!]()\n\n[clojure.core/compare-and-set!]()\n\n[clojure.core/atom]()\n\n[clojure.core/swap-vals!]()\n\n[clojure.core/reset-vals!]()\n\n----\n\n*[/Users/pez/.m2/repository/org/clojure/clojure/1.11.1/<clojure-1.11.1.jar:clojure/core.clj](jar:file:///Users/pez/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jar!/clojure/core.clj)*>"
    }
}

If kondo provides that analysis it should work, otherwise it's a bug in clojure-lsp or kondo, but before I'd check if the classpath is correct as most of the time issues like that are related to classpath

Even if this comes from clojure.core or cljs.core

Server info says:

"classpath": [
    "/Users/pez/.m2/repository/org/clojure/core.specs.alpha/0.2.62/core.specs.alpha-0.2.62.jar",
    "src",
    "/Users/pez/.m2/repository/org/clojure/spec.alpha/0.3.218/spec.alpha-0.3.218.jar",
    "test",
    "/Users/pez/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jar",
    "scripts"
  ],

I have placed a deps.edn file there to help clojure-lsp:

{:paths ["src" "scripts"]}

Ideally I’d wish for a joyride.edn. But that’s a separate story. 😃

so there is no clojurescript deps on the classpath right?

that's the problem I guess, a empty deps.edn includes only clojure.core stuff, for cljs you would need to explicit declare that dep

Thanks! That worked. Even if it doesn’t really make sense to add clojurescript deps, since we’re not using ClojureScript. @U04V15CAJ, what’s the recommended config for nbb?

there is none

Is there a way I can use nbb to calculate the classpath?

Thinking I could do something like so.

{:project-specs [{:project-path "joyride.edn"
                  :classpath-cmd ["npx" "nbb" "-e" ",,,"]}]}

@U0ETXRFEW yes, there is nbb.classpath/get-classpath

Thanks! I’ll have a look!

@U0ETXRFEW if you find some sane default for joyride.edn , we can open a PR on clojure-lsp to consider that project spec as default if that makes sense

Awesome. I’ll try to figure this out.

@U04V15CAJ, it’s a bit unclear to me how to populate the classpath from a map like this

{:paths ["src" "scripts"]
 :deps {org.clojure/clojurescript {:mvn/version "1.11.54"}}}

do you have this in nbb.edn?

No. I could, I guess, but it gets to be a similar problem as having it in deps.edn. Can I tell nbb to look elsewhere for the config?

no

I guess you could make a deps.edn with a joyride alias and configure lsp to include the joyride alias

Ah, yes. Creates a dependency on clojure though. Can I have aliases in nbb.edn?

what do you mean a dependency on clojure

no you can't

I think a good idea would be to have a joyride.edn which would add the clojurescript deps via CLI args in the classpath-cmd of the project spec?

I don’t want a Joyrider to depend on clojure.

nbb.edn depends on bb FWIW, how else did you think it deals with all the maven stuff, magically re-implement everything in Node.js? ;)

Lately I have been considering to bundle bb with Calva. This could push me over to the yes side of that…

you already include deps.clj which is the ingredient used by bb to do all of this maven stuff

Indeed… :thinking_face:

So deps.clj supports custom config files? (Not just deps.edn)

It does, with -Sdeps-file

Great. I don’t want to depend on Java either, but bundling bb or a binary deps.clj might be the way.

deps.clj always depends on java

There’s a binary dist, right?

there is a deps.clj binary but deps.clj is just the clj bash script ported to clojure unless you're going to use tools-deps-native https://github.com/babashka/tools-deps-native

I actually do not care so much what is used. I just want as few dependencies as possible. Joyride is fully usable without any other dependency. I’d like to keep it like that. Here it is OK with a Calva dependency, since it is Calva that wants clojure-lsp to have the classpath.

@UKFSJSM38, does clojure-lsp have a way to resolve classpaths from a deps map?

tools-deps-native looks interesting

@U0ETXRFEW no

Hmmm, this was surprisingly tricky!

Maybe the solution is to make Calva check if bb is installed on the classpath. If it isn’t, install it and help the user get it on the PATH. And then the classpath-cmd in clojure-lsp will use bb if it is installed, otherwise just return whatever is in paths of joyride.edn. WDYT?

That's fine but users will still require java, since bb calls deps.clj I think 99% of joyride users will already have it installed though

Hmm, still java… Then I don’t want to go that way. 😃 I’ll think some more here…

You won't avoid using java no matter what way of entry into deps.clj you will use

Yeah, tools-deps-native may be my only option.

But that creates other problems that I have not yet solved…

I'd say just go with deps.clj since you already have it in Calva - this is just for clojure-lsp right?

Yeah, it’s for creating as nice a dev ux as I can for Joyriders.

Calva could expose a command for calculating a classpath given a .edn file and then call deps.clj

Calva can’t expose anything to command line tools.

deps.clj could also have an option to use tools-deps-native so you can avoid java, but the only thing is, that tools-deps-native I consider an experimental project

I saw the experimental tag. I think that’s fine.

Perhaps you can experiment with this, I'd be open to an option + PR ;)

From a Joyride perspective. I get if you don’t think that way about deps.clj.

what deps.clj could do, given an environment variable DEPS_CLJ_TOOLS_DEPS_NATIVE=true , it could download (instead of the tools jar) the binary

It’s actually not that easy to call deps.clj from the command line either. First I need to know where it is, and VS Code won’t tell me. 😃

maybe try with tools-deps-native only then

$ tools-deps-native

tools.deps.edn ...

          help  show this help message
          deps  output a claspath map from a deps map
  create-basis  output a basis from a set of deps sources and a set of aliases
     root-deps  output the root deps.edn
    slurp-deps  read, canonicalize and output a deps.edn file
user-deps-path  output the path to the users deps.edn file

It’s a bit the same there. But I guess Calva can place it in a known place. Same with deps.clj.

That’s a sweet cli!

"But I guess Calva.." I guess you mean joyride?

Calva or Joyride. I’m undecided. It is Calva that is bringing in clojure-lsp.

$ tools-deps-native deps '{:deps {medley/medley {:mvn/version "1.0.0"}}}'
{:classpath-roots ["/Users/borkdude/.m2/repository/medley/medley/1.0.0/medley-1.0.0.jar" "/Users/borkdude/.m2/repository/org/clojure/clojure/1.7.0/clojure-1.7.0.jar"], :classpath {"/Users/borkdude/.m2/repository/medley/medley/1.0.0/medley-1.0.0.jar" {:lib-name medley/medley}, "/Users/borkdude/.m2/repository/org/clojure/clojure/1.7.0/clojure-1.7.0.jar" {:lib-name org.clojure/clojure}}}

I guess Joyride makes most sense. We are to support a joyride.edn project spec after all.

No Windows binary, right?

ok, would be a nice way to mature tools-deps-native I guess

there is: https://github.com/babashka/tools-deps-native/releases/tag/v0.1.2

Ah, I think I read somewhere that there were only binaries for Mac and Linux.

README is stale

Great that reality wins over the map!

tools-deps-native is also designed to be used in conjunction with tools.bbuild: https://github.com/babashka/tools.bbuild tools.build for bb without java :)

OMG. You are crazy in the most wonderful way.

thanks ;)

It would be nice if I could call tools-deps-native like so:

$ tools-deps-native --deps-file joyride.edn --print-path

dude, you can script right?

I like to think so. 😃 But it’s a bit awkward to script in a vector of command line args. And to make it compatible across platforms.

first make it work, then improve, it seems like you're asking for premature features

you can do this from JS/node.js

which should be relatively OS-friendly

I created an issue for it.

https://github.com/BetterThanTomorrow/joyride/issues/170

I’ll try with scripting it. maybe "npx" "nbb" … is the way to go.

that doesn't make sense to me, I thought you said you wanted to not use bb / java you didn't have to. nbb uses both for resolving deps from nbb.edn

I mean to pipe tools-deps-native’s output to nbb.

why nbb though?

you're already in joyride?

I’m on the command line. No Joyride.

how are you on the command line? I don't get it. Btw, you could write a small JS file as part of joyride's package that you can call from the command line.

e.g. a "bin" entry in the package.json

clojure-lsp asks for a classpath-cmd. That’s what I need to construct.

Still the problem with how the command line should find the Joyride bin directory. There doesn’t seem to be a clean way to do that.

doesn't npx joyride_deps work?

or node_modules/.bin/joyride_deps?

or node_modules/joyride/scripts/deps

what’s joyride_deps?

an imaginary script that you package in joyride's npm package

Ah, so now there’s a joyride npm package? 😃

vscode doesn't have an node_modules dir?

No.

ah righ

t

Well, I guess it has, but it won’t tell us where it is.

perhaps joyride can spit the JS script on startup to some known location

Yes. That should work.

unless clojure-lsp kicks in before joyride ever started ;)

I’ll add this idea to the issue.

We can rely on that Calva is pretty slow to start. And Joyride is very fast. 😃

perhaps we can make an npm package (in squint of course :P) that downloads/caches tools-deps-native and offers a neat JS interface for downloading clojure deps :P

I like.

squint can read edn structures, I am guessing?

It doesn't have EDN on board currently, but you can do it via https://github.com/jorinvo/edn-data Someone has used this from squint quite recently

Cool.

I wonder if this creates a node dependency that we could avoid.

how so?

Something needs to run the JS code?

you want to do the downloading/caching/etc of tools-deps-native rather using bash and powershell?

🎃

you were the one who suggested npx nbb

Yeah, that also has that problem.

We handle the download for deps.clj and clojure-lsp in Calva, so we could do this in Joyride for tools-deps-native too.

right

then "stub" the scripting part for now with bb or nbb and we can optimize that part later in tools-deps-native perhaps

this is the "pre-mature" part that's probably too early to decide on now unless you're 100% certain you're going the tools-deps-native route

Makes sense to me.

Piping to jet also works ;)

$ tools-deps-native deps '{:paths ["src"] :deps {medley/medley {:mvn/version "1.3.0"}}}' | jet -t ':classpath-roots (str/join ":")'
"src:/Users/borkdude/.m2/repository/medley/medley/1.3.0/medley-1.3.0.jar:/Users/borkdude/.m2/repository/org/clojure/clojure/1.9.0/clojure-1.9.0.jar:/Users/borkdude/.m2/repository/org/clojure/core.specs.alpha/0.1.24/core.specs.alpha-0.1.24.jar:/Users/borkdude/.m2/repository/org/clojure/spec.alpha/0.1.143/spec.alpha-0.1.143.jar"

But bb is more flexible since it supports fs/path-separator

The classpath is always separated with :, no?

not on Windows

Haha, wtf.

on Windows it's ;

this is because on Windows you can have colons in paths: c:\Users\...

I’m contacting the developer for more information.

Don't download it through http://Finder.app, but just using curl

or use sudo xattr -c ./tools-deps-native

or use linux 😛

This is with all unsigned binaries, just don't use a GUI to download and unzip them on macOS

or use linux

or Windows ;)

but why even use a GUI if you can use the Terminal ;)

Yeah, Joyride is going to download it without clicking so then this is not a problem. 😃

btw how many deps do you expect joyride users to have in joyride.edn?

The way to solve the GUI problem using the GUI is to right-click the binary and select Open from the context menu. Then click Open in the warning dialog. I think that does something similar to sudo xattr.

I think only the for the ones that are built-in joyride. ClojureScript, rewrite-clj, promesa, and such.

right and some :paths ?

Four paths to begin with, I think. src, script, ~/.config/joyride/src, and ~/.config/joyride/scripts.

Though I am thinking joyride.edn could also be used to configure more paths for Joyride, WDYT?

that's what I wondered about

This almost works (if I forget about windows for a moment)

{:project-specs [{:project-path "joyride.edn"
                  :classpath-cmd ["bash" "-c" "$HOME/binaries/tools-deps-native deps \"`< joyride.edn`\" | jet -t ':classpath-roots (str/join \":\")'"]}]}

add println

or use bb

println doesn’t do it

oh, yes, Last in the thread… now it works.

Well, this command line works:

$HOME/binaries/tools-deps-native deps "`< joyride.edn`" | jet -t ':classpath-roots (str/join ":") println'

I can’t shake the feeling that the interface of tools-deps-native could be a bit less demanding.

well sure, the interface is just a quick hack to see if stuff works

it's an experiment you know

I like it the experiment. 😃 Just that for my use case an interface where I could have it read a file and spit out the path would remove the need of binaries and the problem with windows compatibility.

the need of binaries?

more binaries than tools-deps-native.

feel free to submit a PR of whatever you need, as long as you also add tests

I probably will. Next week. I used up this week’s budget for this in trying and failing to get the command line to work. 😃

• Just to make sure, that's not related with clojure or clojure-lsp right? • I agree the yamlls is crashing when starting which is bad • emacs is probably not finding yaml-language-server in the PATH, one way to test that is start emacs from terminal which should inherit the PATH env, you can check that with (getenv "PATH") i think

It's not related to clojure. Your right, I'm just so used to asking lsp questions here. -_-.

what have you got lsp-yaml-server-command set to? From the error, it looks like it's trying to execute /home/drewverlee/.emacs.d/.cache/lsp/npm/yaml-language-server/bin/yaml-language-server (does that file exist?) How have you installed npm? Are you using nvm? That will change where npm install -g puts it's files. When I install the yaml server lsp-mode seems to run

/usr/bin/npm -g --prefix /var/home/ed/.emacs.d/.cache/lsp/npm/yaml-language-server install yaml-language-server

yamls server seems to be broken on my Linux system for Emacs 29. Running Emacs from a desktop launcher did not have npm on the path, so it was not picked up by Emacs. Adding npm to the path in the .profile configuration file allowed the server to be installed (manually, via lsp-server-install). Although yamls is installed it still seems to fail at startup or when opening a .yaml file

LSP :: yamlls has exited (exited abnormally with code 127)

> I went ahead did that (i think i already had those packages), and restarted emacs but it had no effect. I assume emacs can find them correctly as i used -g. You're right, the logs show you already had those packages. lsp-mode does that for you "automatically". To see the installation for yourself, uninstall the global, delete the .cache/npm/... binary and visit the yaml again. (calling lsp-install-server with the universal argument (C-u) also forces a reinstall).

if yamls is broken maybe installing yamllint and enabling yaml-yamllint in flycheck would be good enough?

thanks for the suggestions everyone.