Use in production?

[viebel]

What is your recommendation about using scope-capture in production so that we could connect to a nREPL (e.g. with lein) and inspect our code?

Is there a way to dynamically load scope-capture ?
Is it safe to include scope-capture to our code base ?

[gphilipp]

I’ve never used it in production, but in staging yes. As long as it’s on the classpath when the process is started you can just repl in and require it from any namespace.

[vvvvalvalval]

I have no absolute recommendation, but here are some things to consider:

Is it safe to include scope-capture to our code base ?

1. Forgetting a (sc.api/spy ...) call somewhere in your code is a fantastic way to get a memory leak, since each recorded scope gets saved in a global atom and won't get garbage-collected.
2. Of course, this issue might be less problematic if your program is typically short-lived and accumulating garbage can't do much harm.
3. Personally, I'm very forgetful, so to guard against this sort of mistake I don't even include the dependency in production.
4. You might make a different choice; just be careful, and consider using sc.api/dispose-all! to clean up after yourself.

Is there a way to dynamically load scope-capture ?

I guess the situation for scope-capture is the same as for any dependency-free Clojure library:

1. Wherever you can get a REPL running, it's theoretically possible to load scope-capture dynamically (proof: you can just eval each source file in dependency order). In practice, depending on your tooling / setup, that might be more or less tedious. I reckon it works out-of-the-box in Cursive. I've never tried though.
2. AFAICT, it's almost certainly impossible to do in advanced-compiled ClojureScript.

Does that answer your questions @viebel ?

[vemv]

@vvvvalvalval : for completeness, other than a plain' ol mem leak (due to the atom), is there any other significant impact in terms of performance or correctness?

[vvvvalvalval]

is there any other significant impact in terms of performance or correctness?

@vemv for performance, nothing I can think of - the sources of overhead are the effects of saving to the atom and logging.

For correctness, the main risk is that the sc.api/spy macro does side-effects at macro-expansion. Some compilation toolchains may rely on the assumption that macro-expansion is purely functional, and thus avoid re-doing macro-expansion when you would like it to. That kind of stuff.