Fork me on GitHub
#calva
<
2021-09-26
>
introom13:09:37

I have a package xx.yy.zz/ containing clj files. Now I want to rename the package to xx.yy.aa. However, after I “rename” with VSCode, the files in the xx.yy.zz, for example, xx.yy.zz.some_ns is still xx.yy.zz.some_ns instead of xx.yzz.aa.some_ns.

pez13:09:31

Calva doesn't have any rename support.

introom14:09:12

Do you manually rename files or without aided support?

pez14:09:24

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. 😃

ericdallo14:09:54

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

👍 1
ericdallo14:09:34

You can rename namespaces via the ns form though

ericdallo14:09:56

But I don't think it solves your exactly issue

introom13:09:47

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

ericdallo13:09:58

you can hover over the foo.bar here:

(ns foo.bar
 ...
 ..)
and call rename, it will rename all references + file name

👍 1
introom14:09:33

Cool. This works.

paulbutcher16:09:17

Now that I have clojure-lsp and clj-kondo starting up successfully (thanks @ericdallo!) I’m cleaning up the warnings that arise. Most make perfect sense, but I seem to have a heisenwarning? I have a “placeholder” test file containing:

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

(deftest simple-test
  (is (= (+ 1 2) 3)))
When I start VSCode, this file is coloured orange to indicate that it contains warnings, and sure enough when I hover the mouse over it, the tooltip says “1 problem in this file”. But when I open the file, the warning disappears and the file is no longer coloured orange. What might be causing this?

ericdallo16:09:57

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

paulbutcher16:09:29

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?

ericdallo16:09:31

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

paulbutcher16:09:39

Ah! Snap. Thanks!

paulbutcher16:09:00

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

paulbutcher16:09:04

(and thanks again)

👍 1
ericdallo16:09:10

good, makes sense

ericdallo16:09:40

next release should happen this week

bringe01:09:22

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?

paulbutcher08:09:13

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/

☝️ 1
introom13:09:59

OT, but your seven-concurrency book is awesome.

😊 1
paulbutcher16:09:37

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

bringe00:09:08

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.

bringe00:09:29

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.)

😊 1
paulbutcher12:10:07

@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?

paulbutcher12:10:11

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
	]
}

ericdallo13:10:36

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

paulbutcher14:10:22

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)))

paulbutcher14:10:01

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.

ericdallo14:10:24

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

ericdallo14:10:00

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

paulbutcher14:10:59

Will do 👍

👍 1
paulbutcher14:10:01

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.

ericdallo14:10:27

Oh, that's bizarre, I confirmed the issue

ericdallo14:10:04

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

paulbutcher14:10:06

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

ericdallo14:10:27

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

ericdallo14:10:18

I have something in mind, let me check

paulbutcher14:10:39

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.

ericdallo14:10:51

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

(defproject dummy "0.0.1")
To avoid bizarres issues

ericdallo14:10:14

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

paulbutcher14:10:19

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

paulbutcher14:10:27

Oh! Now I’m confused

paulbutcher14:10:45

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"])

paulbutcher14:10:50

And I have the heisenwarning

ericdallo14:10:06

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"])

ericdallo14:10:23

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

paulbutcher14:10:32

Thats … odd!

ericdallo14:10:40

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

ericdallo14:10:48

probably something to fix on clojure-lsp

ericdallo14:10:59

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

paulbutcher14:10:01

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

ericdallo14:10:29

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

paulbutcher14:10:33

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.

ericdallo14:10:55

yeah, that'd be good

paulbutcher14:10:06

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

paulbutcher14:10:33

Thanks (again!) for your help.

👍 1
paulbutcher15:10:30

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.

paulbutcher15:10:42

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

ericdallo15:10:38

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

paulbutcher15:10:53

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

🆒 1
ericdallo15:10:02

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

ericdallo15:10:23

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"}
and this for some reason would scan the test/clj 2 times or something

ericdallo15:10:51

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

ericdallo16:10:39

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
it seems to me that kondo could be smart enough to know that ns was already analyzed WDYT?

borkdude16:10:27

I think so yeah

borkdude16:10:39

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

ericdallo16:10:16

yeah, looks valid to me

borkdude16:10:22

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

ericdallo16:10:59

thanks! I'll raise an issue as start