Fork me on GitHub
#cider
<
2023-04-25
>
Peter Tonner19:04:49

is there a way to make the REPL require a specific namespace on startup? I tried adding "(require '[foo.bar])" to cider-repl-init-code but it doesn't seem to work

practicalli-johnny08:04:59

Tool independent approach is to include a user.clj file on the class path when starting the repl. The code in this user namespace will be loaded during the repl start, so other namespaces can be required, tools run or services started An example for Clojure CLI https://practical.li/clojure/clojure-cli/repl-startup/

👍 2
practicalli-johnny08:04:55

The same can be done for Leiningen by including the dev directory (that contains user.clj) on the class path via an alias / dev profile

practicalli-johnny08:04:11

I use the dev/user.clj to great effect in the Practicalli REPL Reloaded workflow, which launches Portal data inspector, starts a log publisher, requires namespaces for supporting dev tools, etc https://practical.li/clojure/clojure-cli/repl-reloaded/

Peter Tonner11:04:07

oh thanks duh! I have been using user/dev.clj for various operations but keeping them under a comment block so they didn't execute immediately. should have occurred to me to do the opposite for stuff I want to run automatically 😁

Drew Verlee03:04:51

@U05254DQM what if you want a want a project user.clj and a global user.clj. Where the global collects all the libs and functions that I use to build app, but don't want to be included in the app.

Drew Verlee03:04:07

What will happen if there are two user.clj namespaces on the path? (i can try this but the behavior might not be obvious) my goal isn't really to use a user.clj namespace, but to layer on development tooling. I can

practicalli-johnny07:04:58

@U0DJ4T5U1 in my view the dev/user.clj is separate from the application, as it is not packaged along with it. Clojure CLI aliases in the user (global) deps.edn provide project independent tools, or common tools can be installed as a Clojure CLI tool. In theory a separate project could be used that contains just the user namespace code and include that as a development dependency (Clojure CLI alias). This could be effective if all the libs and functions were applicable to every project. Usually there are some project specific variations to manage. I have not tried this and cannot guarantee it works, especially if each project also has its own user namespace defined with different or conflicting function definitions. Tests would need to be done to see if the loading order is consistent, especially if one user namespace defined the same function name with a different body. Having a user namespace with lots of libraries required will affect startup speed, although using reqiring-resolve may mitigate that issue to some extent Using a project template that includes a dev/user.clj configuration is arguably the most effective way to provide a common set of libs and functions. The template can include rules to tailor how the project is created so that any specific function implementation or library require forms are used. This is what I'm doing with the https://github.com/practicalli/project-templates project

🙏 2
Drew Verlee07:04:17

@U05254DQM that makes sense. I should probably not have any projects defining a user.clj ns and let the users do that 😕 .

practicalli-johnny07:04:16

Sorry, I don't follow the reasoning to not include a dev/user.clj file Are the 'users' not going to take advantage of the added develop tools you are using with the project? Happy to discuss specifics in separate thread in #CJTRRQ857 channel