How to reload a clojure file in REPL

Asked 5/10, 2011 at 9:9 Answered 2/12, 2015 at 10:53

Solved clojure reload read-eval-print-loop leiningen

192

What is the preferred way of reloading functions defined in a Clojure file without having to restart the REPL. Right now, in order to use the updated file I have to:

edit src/foo/bar.clj
close the REPL
open the REPL
(load-file "src/foo/bar.clj")
(use 'foo.bar)

In addition, (use 'foo.bar :reload-all) does not result in required effect, which is evaluating the modified bodies of functions and returning new values, instead of behaving as the source haven't changed at all.

Documentation:

Barnett answered 5/10, 2011 at 9:9 Comment(5)

(use 'foo.bar :reload-all) has always worked fine for me. Also, (load-file) should never be necessary if you have your classpath set up right. What is the "required effect" you're not getting? – Thrall 5/10, 2011 at 12:49

Yes, what is the "required effect"? Post a sample bar.clj detailing on the "required effect". – Pinole 5/10, 2011 at 17:41

By required effect I meant that if I had a function (defn f [] 1) and I changed its definition to (defn f [] 2), it seemed to me that after I issue (use 'foo.bar :reload-all) and call the f function it should return 2, not 1. Unfortunately it doesn't work that way for me and every time I change the body of function I have to restart the REPL. – Barnett 5/10, 2011 at 19:33

You must have another problem in your setup... :reload or :reload-all should both work. – Weak 19/2, 2016 at 17:4

Will you post a transcript of your REPL? – Weak 28/10, 2022 at 16:5

226

Or (use 'your.namespace :reload)

Hammad answered 2/12, 2013 at 21:12 Comment(1)

:reload-all should also work. The OP specifically says it doesn't, but I think there was something else wrong in the OP's dev environment because for a single file the two (:reload and :reload-all) should have the same effect. Here's the full command for :reload-all: (use 'your.namespace :reload-all) This reloads all the dependencies, too. – Weak 19/2, 2016 at 17:7

There is also an alternative like using tools.namespace, it's pretty efficient:

user=> (use '[clojure.tools.namespace.repl :only (refresh)])

user=> (refresh)

:reloading (namespace.app)

:ok

Gerrilee answered 12/4, 2013 at 12:50 Comment(3)

this answer is more proper – Trixy 4/12, 2014 at 12:52

Caveat: running (refresh) seems to also cause the REPL to forget that you've required clojure.tools.namespace.repl. Subsequent calls to (refresh) will give you a RuntimeException, "Unable to resolve symbol: refresh in this context." Probably the best thing to do is to either (require 'your.namespace :reload-all), or, if you know you're going to want to refresh your REPL a lot for a given project, make a :dev profile and add [clojure.tools.namespace.repl :refer (refresh refresh-all)] to dev/user.clj. – Stillwell 3/1, 2015 at 18:57

Blogpost on the Clojure workflow by the author of tools.namespace: thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded – Epistaxis 14/7, 2019 at 11:49

Reloading Clojure code using (require … :reload) and :reload-all is very problematic:

If you modify two namespaces which depend on each other, you must remember to reload them in the correct order to avoid compilation errors.

If you remove definitions from a source file and then reload it, those definitions are still available in memory. If other code depends on those definitions, it will continue to work but will break the next time you restart the JVM.

If the reloaded namespace contains defmulti, you must also reload all of the associated defmethod expressions.

If the reloaded namespace contains defprotocol, you must also reload any records or types implementing that protocol and replace any existing instances of those records/types with new instances.

If the reloaded namespace contains macros, you must also reload any namespaces which use those macros.

If the running program contains functions which close over values in the reloaded namespace, those closed-over values are not updated. (This is common in web applications which construct the "handler stack" as a composition of functions.)

The clojure.tools.namespace library improves the situation significantly. It provides an easy refresh function that does smart reloading based on a dependency graph of the namespaces.

myapp.web=> (require '[clojure.tools.namespace.repl :refer [refresh]])
nil
myapp.web=> (refresh)
:reloading (myapp.web)
:ok

Unfortunately reloading a second time will fail if the namespace in which you referenced the refresh function changed. This is due to the fact that tools.namespace destroys the current version of the namespace before loading the new code.

myapp.web=> (refresh)

CompilerException java.lang.RuntimeException: Unable to resolve symbol: refresh in this context, compiling:(/private/var/folders/ks/d6qbfg2s6l1bcg6ws_6bq4600000gn/T/form-init819543191440017519.clj:1:1)

You could use the fully qualified var name as a workaround for this problem but personally I prefer not having to type that out on each refresh. Another problem with the above is that after reloading the main namespace the standard REPL helper functions (like doc and source) are no longer referenced there.

To solve these issues I prefer to create an actual source file for the user namespace so that it can be reliably reloaded. I put the source file in ~/.lein/src/user.clj but you can place in anywhere. The file should require the refresh function in the top ns declaration like this:

(ns user
  (:require [clojure.tools.namespace.repl :refer [refresh]]))

You can setup a leiningen user profile in ~/.lein/profiles.clj so that location you put the file in is added to the class path. The profile should look something like this:

{:user {:dependencies [[org.clojure/tools.namespace "0.2.7"]]
        :repl-options { :init-ns user }
        :source-paths ["/Users/me/.lein/src"]}}

Note that I set the user namespace as the entry point when launching the REPL. This ensures that the REPL helper functions get referenced in the user namespace instead of the main namespace of your application. That way they won’t get lost unless you alter the source file we just created.

Hope this helps!

Dishman answered 22/9, 2014 at 17:16 Comment(17)

Good suggestions. One question: why the ":source-paths" entry above? – Plunk 10/2, 2015 at 1:10

OK, found the answer. The file "user.clj" needs to live somewhere, and a good place is "/home/alan/.lein/user.clj" (on linux). For lein to find the file, we need a file "/home/alan/.lein/profiles.clj " with an entry like: ':source-paths [ "/home/alan/.lein" ' – Plunk 10/2, 2015 at 5:2

Exactly, having an actual source file makes it possible to reliably reload that file and the namespace within. Here is the file I'm currently using: github.com/Dirklectisch/.lein/blob/master/src/user.clj – Dishman 2/3, 2015 at 15:44

@fl00r Sorry not quite getting your point. It should be :source-paths in this case since we are loading source files not other resources. – Dishman 31/3, 2015 at 12:5

@DirkGeurs, with :source-paths I get #<FileNotFoundException java.io.FileNotFoundException: Could not locate user__init.class or user.clj on classpath: >, while with :resource-paths everything is ok. – Additament 31/3, 2015 at 12:44

@Additament Have you created the source file user.clj? "To solve these issues I prefer to create an actual source file for the user namespace so that it can be reliably reloaded." – Dishman 3/4, 2015 at 12:54

Yes I did. Now it is stored in ~/.lein/user/user.clj with other stuff – Additament 3/4, 2015 at 13:7

@Additament and it still throws that error? Do you have a valid project.clj in the folder you are launching the REPL from? That might fix your problem. – Dishman 3/4, 2015 at 13:11

Yes, it is pretty standard, and all works fine with :resource-paths, I am in my user namespace inside repl. – Additament 3/4, 2015 at 13:26

if that's the case, then the clojure repl really sucks. – Cithara 18/5, 2017 at 4:17

I'm doing a tutorial. Is it ok if I reload-all there? – Bogusz 20/12, 2019 at 8:35

@Bogusz Yes you will probably be alright or at least you will notice soon enough if you hit one of the cases described above. – Dishman 20/12, 2019 at 14:28

I just had a great time working with a REPL that was lying to me because of this reload issue. Then it turned out everything I thought was working was not anymore. Maybe somebody should fix this situation? – Bogusz 20/12, 2019 at 23:52

@Bogusz I don't think they will address this any time soon in the language. tools.namespace is you best bet. Cool to hear that you are trying out Clojure. There is a lot to love there. – Dishman 21/12, 2019 at 10:34

Hey! It seems like that and now that I got setup with Calva at a basic level things are looking up. – Bogusz 21/12, 2019 at 21:0

Can tools.namespace helps somehow to reimport recompiled Java classes as well? – Cameral 2/7, 2020 at 20:42

@Additament Seems :source-paths indeed cause an error when lein repl called in folder without project.clj (while :resource-paths does not) – Cameral 2/7, 2020 at 22:49

The best answer is:

(require 'my.namespace :reload-all)

This will not only reload your specified namespace, but will reload all dependency namespaces as well.

Documentation:

require

Plunk answered 3/8, 2014 at 6:29 Comment(3)

This is the only answer which worked with lein repl, Coljure 1.7.0 and nREPL 0.3.5. If you're new to clojure: The namespace ('my.namespace) is defined with (ns ...) in src/.../core.clj, for example. – Studer 25/7, 2015 at 14:32

The problem with this answer is that the original question is using (load-file ...), no require. How can her add the :reload-all to the namespace after the load-file? – Trotskyite 21/5, 2018 at 13:49

Because the namespace structure like proj.stuff.core mirrors the file structure on disk like src/proj/stuff/core.clj, the REPL can locate the correct file and you don't need load-file. – Plunk 21/5, 2018 at 14:32

One liner based on papachan's answer:

(clojure.tools.namespace.repl/refresh)

Panda answered 24/4, 2015 at 20:35 Comment(0)

I use this in Lighttable (and the awesome instarepl) but it should be of use in other development tools. I was having the same problem with old definitions of functions and multimethods hanging around after reloads so now during development instead of declaring namespaces with:

(ns my.namespace)

I declare my namespaces like this:

(clojure.core/let [s 'my.namespace]
                  (clojure.core/remove-ns s)
                  (clojure.core/in-ns s)
                  (clojure.core/require '[clojure.core])
                  (clojure.core/refer 'clojure.core))

Pretty ugly but whenever I re-evaluate the entire namespace (Cmd-Shift-Enter in Lighttable to get the new instarepl results of each expression), it blows away all old definitions and gives me a clean environment. I was tripped up every few days by old definitions before I started doing this and it has saved my sanity. :)

Fresnel answered 2/12, 2015 at 10:53 Comment(0)

Try load-file again?

If youre using an IDE, there's usually a keyboard shortcut to send a code-block to the REPL, thus effectively re-defining the associated functions.

Berkey answered 5/10, 2011 at 12:5 Comment(0)

As soon as (use 'foo.bar) works for you, it means that you have foo/bar.clj or foo/bar_init.class on your CLASSPATH. The bar_init.class would be an AOT-compiled version of bar.clj. If you do (use 'foo.bar), I'm not exactly sure if Clojure prefers class over clj or the other way round. If it would prefer class files and you have both files, then it's clear that editing the clj file and then reloading the namespace has no effect.

BTW: You don't need to load-file before the use if your CLASSPATH is set properly.

BTW2: If you need to use load-file for a reason, then you can simply do it again if you edited the file.

Mauldin answered 2/2, 2012 at 20:35 Comment(2)

Not sure why this is marked as the correct answer. It doesn't answer the question clearly. – Nigro 12/6, 2013 at 13:48

As someone coming to this question, I don't find this answer very clear. – Cenogenesis 5/9, 2013 at 13:9

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags