This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (9)
- # beginners (90)
- # cider (98)
- # cljs-dev (23)
- # cljsrn (4)
- # clojure (101)
- # clojure-brasil (3)
- # clojure-dev (48)
- # clojure-italy (15)
- # clojure-losangeles (3)
- # clojure-russia (12)
- # clojure-uk (17)
- # clojured (1)
- # clojurescript (141)
- # community-development (15)
- # core-async (1)
- # datascript (12)
- # datomic (18)
- # docker (3)
- # emacs (1)
- # events (1)
- # figwheel (1)
- # fulcro (57)
- # graphql (4)
- # jobs (1)
- # lein-figwheel (1)
- # leiningen (1)
- # lumo (1)
- # off-topic (68)
- # om (9)
- # om-next (3)
- # onyx (4)
- # parinfer (6)
- # pedestal (14)
- # portkey (2)
- # proton (1)
- # protorepl (19)
- # re-frame (57)
- # reagent (46)
- # ring-swagger (12)
- # shadow-cljs (167)
- # slack-help (5)
- # specter (18)
- # sql (1)
- # uncomplicate (3)
- # unrepl (1)
@alexmiller do you have any suggestions how I should go about getting eyes on https://dev.clojure.org/jira/browse/TNS-48. I'm not sure what's the best way to reach out to stuart sierra or clojure contrib to start a conversation about it
Sorry, I don’t have a good suggestion for you. Stuart is the current project owner and I would defer to him on this enhancement. I think it would be reasonable to bring it up on the clojure mailing list.
^ on that point would it be preferable to use the
clojure-dev mailing list?
I'd use the
clojure-dev mailing list first and give it a few days. Then try
But it could just be that Stuart is busy -- he's definitely gotten your emails from JIRA -- and hasn't yet formulated a response.
I try to acknowledge comments within a day or two but often don't have a considered response for several weeks on the projects that I maintain @rymndhng
thanks for the advice, i definitely want to tread lightly, not trying to stalk 👻 haha
@rymndhng I've been maintaining open source projects for about 25 years... it's always interesting how "urgent" one user's issue can be compared to the hundreds or thousands of other users of any given piece of software 🙂 It's hard, as a maintainer, to ensure everyone feels listened to -- but it can also be pretty overwhelming when users demand your time, especially if you maintain a number of projects and you have a full time job too.
There are issues that have been open on
clojure.java.jdbc for years, not because I don't care, or I think they're not important, but because I don't have a good solution even after lots of thought and the solutions suggested in the issues don't really work for me.
I took a look at TNS-48 and my initial reaction was discomfort with your proposed solution but I can't immediately put my finger on it.
I don't know that namespace metadata is really a good solution -- is there a precedent for it out there? I also wondered about how developers would always know whether there's a specific dependency between an individual namespace and a specific set of files... Would they always be files on the classpath? What about code that depends on files elsewhere on the file system?
it isnt, however it’s de-coupled from the rest of the tooling by using the namespaced key. if you aren’t using tools.namespace, the metadata doesn’t impact your code
i definitely agree with you on not burdening maintaners. I definitely want to approach this change as a conversation with back & forth. As a relative outsider to contrib, it’s tricky to know if I’m going about it the right way b/c it’s a different circle of peers I’m interacting with, so I’m currently skimming on the edges 🙂
Namespace metadata used to be broken in AOT but that was fixed in Clojure 1.8 (CLJ-130)
HugSQL is kind of an interesting case because it relies on a function call in a namespace to read external files and generate new or updated functions. I'm not sure how common that is as an idiom, which also makes me wonder if the solution shouldn't be pushed off on HugSQL somehow...
I think it’s good that it’s a) out of band in metadata and b) tied to a namespace for namespace reloading functionality
Well, reloading config files is the situation we'd face at work, but that's completely handled by Component.
Part of me feels that the problem is HugSQL itself, in the way that it dynamically injects functions based on an external file. Is that idiomatic? Is that something that HugSQL should negotiate with c.t.n for the reloading?
I’d argue that HugSQL and c.t.n shouldn’t be negotiating because it’s not universal that all def-db-fns should auto-reload. I was thinking more of putting the power it in the user’s hands and avoid magic behind the scenes negotation.
Right, but you're asking c.t.n for a mechanism to call for reloads that has nothing to do with the code. What about a library that works like HugSQL but keeps the SQL files in external dynamic storage?
What about a library that dynamically defines functions based on data in Zookeeper, for example?
That's why I asked about files that aren't on the classpath. How far away from the classpath and "file modified" timestamps should you go?
That sounds like feature creep. c.t.n is a development tool and it’s focused on changes to source files & how it maps to namespaces.
But HugSQL files aren't really "source" files -- they're configuration files that are used by function calls to add new functions to the running image.
They’re source in the way they’re files you check into your repo with your clojure code.
But as I've said, that's a very limited view of those sorts of extensions -- configuration files aren't always going to be under version control with your code, for example.
I'm just echoing Stuart's response that some sort of extension to "when to reload this namespace" clearly has value -- but how should that be structured?
Should the metadata be classpath files? Should it be symbols that resolve to functions that should be invoked?
The general problem is that "some metadata" may change and may cause changes to a given namespace without the source file for that namespace actually changing.
I'll give you an example from work: we have specs that we use to drive macros that generate functions. We'd need a way to say "reload this namespace when those specs have changed in certain ways".
All I'm saying is that there are lots of ways a reload dependency could be introduced -- and in my opinion HugSQL is a pretty narrow use case.
For sure, I see your point as going about smaller API is better for consistency and not having feature creep. Again, HugSQL is only one possibility so far for use of this.
We have this issue with clojurescript, macros and localization files. For now it requires us to
touch things to resolve them. I believe that
enlive also suffers from this.
My own half baked attempt at reloading (in enlive) used namespace metadata but dynamically (so no metadata in the source, only in the “image”), when a resource was used in a
defsomething, the macro was adding an entry for it to the live ns metadata.
@cgrand you wrote your own reloader right? So that if the dependency updated, you reloaded the namespace yourself?
@dominicm indeed https://github.com/cgrand/enlive/blob/master/src/net/cgrand/reload.clj but it was half hearted as it wasn’t a pain point for me but users kept asking for it