Calva doesn't have any rename support.

Do you manually rename files or without aided support?

I just rename things manually. Unless there is a case where #lsp can help. It can with some things, I haven’t figured out what works and not so I often try with that first. 😃

LSP can help but we don't have this feature yet: https://github.com/clojure-lsp/clojure-lsp/issues/552

You can rename namespaces via the ns form though

But I don't think it solves your exactly issue

> You can rename namespaces via the ns form though Could you be more explicit on this?

you can hover over the foo.bar here:

(ns foo.bar
 ...
 ..)

Cool. This works.

we had this issue on clojure-lsp but we fixed on latest release I think

When you say latest, you mean released, or waiting to be released? I’m running 2021.09.13-22.25.35 which I believe is the most up to date release?

it was fixed on master but not on latest release: https://github.com/clojure-lsp/clojure-lsp/issues/554 But I know you are probably using the master clojure-lsp

Ah! Snap. Thanks!

I haven’t switched to master yet - will do.

(and thanks again)

good, makes sense

next release should happen this week

I’m curious, how would one use clojure-lsp’s master branch, instead of a release? Do you mean building clojure-lsp from the master branch yourself and pointing Calva to it?

Exactly. There are instructions on how to do so in the section “Using a Custom Clojure-lsp Native Binary” here: https://calva.io/clojure-lsp/

OT, but your seven-concurrency book is awesome.

Thank you @UGC0NEP4Y, that’s very kind of you to say!

Thanks @U5KAD4W2E. I was just curious if there was some other method being used here that I was unaware of. I wrote those instructions in the docs for using a native binary 😄 - glad to know they are being used.

Also, I believe I came across your book once in a book store, and flipped through and was happy to see Clojure mentioned. Awesome coincidence to later chat with you here. 😃 (I just looked it up because of the above comment and remembered the cover.)

@ericdallo I’m running clojure-lsp 2021.09.30-15.28.01 but I’m still getting the same heisenwarning. Is it possible that I’m seeing a different problem from the one you fixed?

The warning I’m getting (now I’ve worked out how to see it - without making it disappear before I can!) is:

{
	"resource": "/Users/paulbutcher/Projects/raceandimprove/race-and-improve/test/clj/race_and_improve/session_test.clj",
	"owner": "_generated_diagnostic_collection_name_#0",
	"code": "redefined-var",
	"severity": 4,
	"message": "redefined var #'race-and-improve.session-test/simple-test",
	"source": "clj-kondo",
	"startLineNumber": 4,
	"startColumn": 1,
	"endLineNumber": 4,
	"endColumn": 1,
	"tags": [
		1
	]
}

It seems a valid kondo finding, could you paste you code or a repro?

It’s the code I pasted above - a “placeholder” test file:

(ns race-and-improve.session-test
  (:require [clojure.test :refer [deftest is]]))

(deftest simple-test
  (is (= (+ 1 2) 3)))

The weird thing (to my mind) is that I see the warning when I open the project, but it disappears the instant I open the file.

That's really odd, never saw this kind of issue with deftest

Is it possible to make a simple repro in a repo so I can investigate?

Will do 👍

Done: https://github.com/paulbutcher/heisenwarning

The problem seems to be related to the “empty project.clj” problem that we hit earlier. Delete the project.clj file, and the problem doesn’t happen.

👀

Oh, that's bizarre, I confirmed the issue

I have no idea why kondo is saying that var was already referred, I'll debug a little more

Thanks. I suspect that it’s the project.clj and deps.edn “fighting” somehow (because delete project.clj and it doesn’t happen).

that's weird as well, I can't find a relation between those things 😂

I have something in mind, let me check

Thanks. Although… The only reason I have the project.clj is to tell Heroku that I’m using Clojure. I’ve just done some digging, and there are other options I could use: https://devcenter.heroku.com/articles/buildpacks#setting-a-buildpack-on-an-application Perhaps the easiest approach would be to do something like that and just delete project.clj.

My suggestion about that is if even you need that project.clj, keep it "valid", like something like:

(defproject dummy "0.0.1")

I confirmed with that dummy project.clj, the issue doesn't happen

As it happens, that is what I have in my “real” project (but I still have the heisenwarning)

Oh! Now I’m confused

This is what I have in my “real” project.clj:

; Unused - only here because the Heroku Clojure buildpack insists upon project.clj being present
(defproject org.example/sample "1.0.0"
  :source-paths ["src/cljs" "src/cljc" "src/clj"])

And I have the heisenwarning

let me try

Hum, I confirmed that doesn't work indeed, but it does work if I change it to :

; Unused - only here because the Heroku Clojure buildpack insists upon project.clj being present
(defproject org.example/sample "1.0.0"
  :source-paths ["src/cljs" "src/cljc" "src/clj"]
  :test-paths ["test/clj"])

for some reason, adding the test-paths remove that duplicated warning

Thats … odd!

I need to take a closer look later to understand why kondo is telling that

probably something to fix on clojure-lsp

but for now, do you think you can just add the test-paths?

Apologies for having such a weird project config (blush!)

no problem, there are those weird issues that make the project mature :)

I think I’m going to experiment with an alternative way to get Heroku to use the Clojure buildpack and avoid this multiple fighting project definitions problem entirely.

yeah, that'd be good

(the empty project.clj also confuses Calva, so it would be good to lose it if I can)

Thanks (again!) for your help.

This is turning into a yak-shave - Heroku’s Clojure buildpack refuses to run if it can’t find a project.clj 😞

-----> App not compatible with buildpack: 
       Could not find a 'project.clj' file! Please ensure it exists and is checked into Git.

I feel a pull request against the buildpack coming on..

yeah, I'm debugging clojure-lsp to see if I can fix that invalid warning, but even so, it makes sense a PR to heroku

Unsurprisingly, I guess, I’ve been beaten to it: https://github.com/raymcdermott/heroku-deps-build-pack

uh, I think I found the issue on clojure-lsp :)

it seems that when you don't tell lein what are the test source-paths ,it uses the default test so it tells to kondo to analyze these folders:

from project.clj
#{"src/cljs" "src/cljc" "src/clj" "test" "src/test/clojure"

from deps.edn
#{"test/clj" "src/clj"}

probably a issue on kondo, I'll try to repro with kondo only

Confirmed the issue! @U04V15CAJ TLDR: if you pass a folder and a file inside that same folder, kondo scan 2 times the same file emitting warnings like var already referred . Ex: Repro: https://github.com/paulbutcher/heisenwarning

$ clj-kondo --lint test test/clj/race_and_improve/session_test.clj 
test/clj/race_and_improve/session_test.clj:4:1: warning: redefined var #'race-and-improve.session-test/simple-test
linting took 116ms, errors: 0, warnings: 1

I think so yeah

at least on the file level, we can track already linted files

yeah, looks valid to me

issue welcome. as for the implementation: I think we could add an atom to the ctx with already linted filenames

or so

thanks! I'll raise an issue as start

https://github.com/clj-kondo/clj-kondo/issues/1395 c/c @U5KAD4W2E