This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-14
Channels
- # aleph (2)
- # announcements (11)
- # aws (4)
- # babashka (42)
- # babashka-sci-dev (81)
- # beginners (90)
- # biff (2)
- # calva (40)
- # cider (16)
- # clj-kondo (26)
- # clj-on-windows (1)
- # cljdoc (4)
- # cljfx (1)
- # cljsrn (2)
- # clojure (92)
- # clojure-austin (2)
- # clojure-europe (23)
- # clojure-nl (5)
- # clojure-uk (3)
- # clojured (3)
- # clojurescript (19)
- # community-development (3)
- # conjure (1)
- # cursive (4)
- # datalevin (3)
- # datomic (5)
- # emacs (13)
- # events (1)
- # fulcro (26)
- # graphql (1)
- # hugsql (15)
- # introduce-yourself (5)
- # leiningen (1)
- # lsp (29)
- # minecraft (19)
- # music (1)
- # off-topic (36)
- # pathom (12)
- # podcasts (2)
- # portal (8)
- # re-frame (12)
- # reagent (11)
- # rewrite-clj (4)
- # shadow-cljs (56)
- # spacemacs (2)
- # vim (12)
- # windows (3)
- # xtdb (43)
Hello, I have a question on the latest release v0.5.2. ⢠fix fn defs to be at compile-time https://github.com/layerware/hugsql/issues/126 (thanks https://github.com/kelvinqian00https://github.com/kelvinqian00)!) Does it work well with leiningen? With leinignen, uberjar with option 'aot all & omit-source' still throws 'Can not read file' exception. Test project: https://github.com/jngbng/hugsql_aot
Honestly, I don't understand why switching 'def-db-fns' from macro to a normal function would prevent executing it on runtime (so that it will not read SQL file on start up.)
@jbseo The assumption is that you are calling (def-db-fns)
as a top-level form in your namespace so when you load the ns (for compilation) it runs and loads the SQL and defines all the functions. If you're calling (def-db-fns)
anywhere, it's not going to work.
Yes, I did call it on top-level from in my namespace: https://github.com/jngbng/hugsql_aot/blob/master/src/hugsql_aot/db.clj
(at least, that's my reading of the changes made in 0.5.2)
With the following file:
(ns hello.echo)
(prn "I am hello.echo")
I will see the greeting message both on AOT compilation time and on starting the program. Am I right?I'm just guessing at their intent: I'm not saying it actually works if the source is not present in the JAR file š I don't know how well it has been tested...
In #126, the OP says "Indeed it does work! (Plus the conversion from using macros to regular functions cleans up the core code.)" so the solution worked for their use case...
(that convo suggests it does work for them since they are excluding .sql
files from their JAR...)
Yes, so I wonder how it could be possible. With the definition of https://github.com/layerware/hugsql/blob/ad73d080f84487c3438058ed5203d44f06c46365/hugsql-core/src/hugsql/core.clj#L530, I think it should read SQL file on start up time.
I just tried it with your repro project and even with a few tweaks and edits, I cannot get it to work "as advertised" so it definitely "doesn't work" as I would expect.
You could create a new issue and link back to #126 and your repo.
Yes, this is still not working (even with depstar as in the original issue). I've updated that bug, and will try to get a fix out in the next few days. I'll probably switch back to macros.
It's a tricky one -- and macros vs functions is irrelevant I think since the issue is about invocation at load time which happens for both compilation and for running in a standalone JAR.