The problem I had been wrestling with was communicating with the test controller server, handling intricacies of the LSP flavor of JSONRPC. Being able to use the nvim JSONRPC machinery without the LSP request requirements means this project now really is just writing handlers for the requests

References in the docstring specifically call out LSP, but `vim.lsp.rpc` starts a command and communicates using the LSP flavor of JSONRPC. Unlike `vim.lsp`, the RPC module *does not* automatically send the typical LSP initialize request.

Long story short, after discussions + poring over the nvim code, I found there is a non-LSP implementation of JSONRPC available natively via `vim.lsp.rpc`

github.com/neovim/neovi...

Once Julia communication is working, the neotest interface is (moderately) well documented. So ideally we'll get the usual "running/passed/failed/watch file" features easily. That part is just data manipulation so hopefully quick to implement- moving the data around is the awkward part, so far

Making it work generally is the next step. There's some Lua-JSONRPC.jl communication that needs to be tightened up, some LSP calls to properly fill out the test item information. I expect the nvim side of communicating via stdio is the "hard" part, but that is primarily a Lua problem

#neovim #nvim #julialang since I forgot to tag these along the way

Right now this is just a Lua file on my machine pointing to some tests that have a JSON payload generated by what `neotest-julials` outputs at the moment. BUT! The all the constituent pieces are there, it's just a matter of gluing it all together now

Also need to pull the Project/Package URI and data as per this LSP call, so that needs to be added

github.com/julia-vscode...

Had to do a type conversion in the Julia code (not sure why a specific Dict is oddly-typed), and I'm hard-coding some hashes + IDs, but these are basic pieces that can be built in.

I've purposefully avoided coding with AI to this point. What is the utility you're gaining given the "often wrong" nature?

I'm interested in compelling reasons or situations to try with it, not entirely skeptical

In practice, outside of open source and working across multiple teams, I find that the present tooling (and time, in industry, but that's a separate issue) to support hand-rolling these testers is lacking. Perhaps that's a sign to improve my PBT/generic test writing skills

Writing proper testers for "interfaces" is good practice regardless, as you said. In a perfect world, we get something like CRTU for all meaningful interfaces. Especially for anything load-bearing and intended to compose

Agreed entirely w/r/t productivity without interfaces. As much as I daydream at times about being able to have statically inferable Julia end to end, the dynamic nature of the language is important

It's something I get by without most of the time, but I use it when I can. None of it is very ergonomic, and it's all just "check the method table" right now

Culture is definitely a big part. Very few packages actually adopt the idea, and people are productive without it.

And finally, the talk I gave that helped me formalize my views on this topic. The talk is primarily a survey of the topic rather than a technical proposal. Nevertheless, I hope it can serve as a jumping off point

"Building Confidently in Julia with Interface Driven Design"

youtu.be/mMO9NzkTxL0

I do have thoughts on how to codify interfaces/design patterns with them. I've written interface checkers and used several of them; they are all needs suiting at the moment, but there's always room for improvement.

I have an upcoming sabbatical, hopefully I can spend some time on this problem then

Further, at JuliaCon last summer, there seemed to be myriad discussions around interfaces. My talk sparked some personal conversations, Guillaume and Rafael gave a talk on Interfaces.jl, and Lillith included some discussion of traits + interfaces in her talk as well. People care about this problem!

Fortunately, there is movement beyond user-developed packages: Keno recently developed a "roadmap for interfaces"

None of this is course binding, but interest from a core developer of the language is a promising sign

hackmd.io/BbEw0_B4Q8uD...

Right now, the state of the art here is something like Interfaces.jl or RequiredInterfaces.jl to define and check (via your test suite) interfaces. Ideally, a library author would expose a testing utility to verify this interfaces. An elaborate checker could even do some property based testing!