Fork me on GitHub
#clj-kondo
<
2019-10-28
>
whilo09:10:27

@borkdude what would be necessary to provide a linter for the datalog query DSL arguments to datomic, datahike or datascript's q function?

whilo09:10:07

@kordano this would probably pay off for our development work already

borkdude09:10:02

I think the following: 1) determine which fully qualified function calls need datalog linting 2) write a function that lints the datalog expression 3) combine 1 and 2 4) write unit tests 5) profit!

borkdude09:10:06

note that clj-kondo works with nodes instead of direct sexps values, but you can convert a node into it's corresponding sexp.

borkdude09:10:37

but it's preferable to work with nodes directly as you can be more specific in error locations and you can detect errors in the representation that would not even compile

borkdude09:10:58

I'd be happy to stub out the start of this issue so you can fill in the rest of the details

whilo09:10:02

ok, cool. i can easily provide a function that calls the datalog parser and returns either an error or whatever truthy value required

borkdude09:10:14

feel free to create an issue, some examples of expected inputs + errors and a link to that function

borkdude09:10:32

I might have to port that function to clj-kondo or use it directly, depends.

dave16:10:37

https://clojurians.slack.com/archives/CHY97NXE2/p1572175726225800 ^this was an interesting discussion, wanted to offer my 2ยข i think i can't even reach a consensus with myself on this one! sometimes i like the aliases all being uniform, and in some cases, i like to be able to name them differently imagine if you have a foo.api namespace that has been superceded by a foo.api2 namespace now imagine that you have a bar namespace that used to consume the foo.api namespace, so the ns declaration included [foo.api :as api]. and imagine that you want to migrate to the newer foo.api2, but the situation is kind of hairy and you need to still depend on something from foo.api too, for a while. so now bar needs to depend on both foo.api and foo.api2 we actually have a scenario like that at work, and we addressed it by requiring [foo.api2 :as api] and [foo.api :as oldapi]

dave16:10:30

so the issue there is that foo.api is aliased as api in some namespaces, and oldapi in others

borkdude16:10:52

and you would like to have them consistent?

borkdude16:10:00

because it's an error to use oldapi?

dave16:10:48

i think i like being able to use a different alias for foo.api in different namespaces, because i'm bringing it in within a different context

dave16:10:02

like in some namespaces, foo.api really is the "api," in others it's the "old api"

borkdude16:10:22

@dave well, there is the analysis export and you can write any kind of script with 2-for-Tuesday's in it that you want ๐Ÿ™‚

dave16:10:34

i think that's a good solution ๐Ÿ˜„

dave16:10:48

i agree with dominic that there isn't consensus about this

dominicm16:10:32

@dave I would be very sad working on that. I'd never know if I could trust whether what I was looking at would do what I expected, because it might be old or new api. So I'd be constantly jumping to the ns form to remind myself any time I was looking at code using either.

borkdude17:10:08

yeah, I guess you could just call the old api old-api/ everywhere

dominicm17:10:13

I'd be fine with api2 for the new one until fully migrated. Although a linter would help me trust that people have done the right thing with being consistent.

๐Ÿ‘ 4
dave17:10:03

hmm, that's a good point. i think i like the idea of the linter telling you about inconsistencies, and therefore encouraging you to come up with different aliases for different namespaces

dave17:10:25

i.e. don't call the old api "api" if there is also a new api that is being called "api" elsewhere

dave18:10:12

hmm, which raises an interesting question... if i have a namespace that requires pears :as p, and then another namespace that requires peaches :as p, is that a problem?

dave18:10:38

or is it just that you can't have pears :as p in one namespace, and pears :as pr in another namespace?

dave18:10:48

i'm thinking it's the latter

dominicm18:10:18

p should be consistent in what it refers to. So I'd go with "both".

dave18:10:06

i'm pretty sure i agree

dave18:10:25

as you're working in a project, you come to learn what p/ means in general

dave18:10:39

so you don't have to keep referring back to the ns form in whatever file you're editing

๐Ÿ‘ 8
borkdude18:10:32

starting to make sense

borkdude18:10:52

what about libraries on the classpath? clj-kondo doesn't know what's a library and your own code

borkdude18:10:05

of course you can lint different directories with different configurations

dave18:10:23

i don't think you would want to apply these rules across "projects"

borkdude18:10:42

right, I mean when you do clj-kondo --lint $(lein classpath)

dave18:10:49

like if i'm using cheshire, and cheshire refers in clojure.string as s, then i don't want to not be able to call something else s in my project

borkdude18:10:57

but you do that only to populate the cache, so that's fine, you can ignore the warnings there

borkdude18:10:21

so this could be a linter, I guess ๐Ÿ™‚

borkdude18:10:13

feel free to comment on it and to provide ideas, alternatives

borkdude18:10:40

maybe the value in the config map should also be a map so it can take options, like: except in this namespace

borkdude18:10:04

but maybe the point of this linter should be that it's consistent without exceptions ๐Ÿ˜‰

dave18:10:46

i have a comment -- will add it to the issue

borkdude19:10:47

added a comment

borkdude19:10:05

added one more

borkdude22:10:59

^ added some developer docs (design principles, but also practical things like how do you get a REPL)