Fork me on GitHub
#cursive
<
2018-10-09
>
stijn08:10:58

@chrisadegraaf is this to have REPL history in a file? the way I usually do this is by adding the source root to a leiningen profile or deps.edn alias. every developer can setup its own aliases and include files the way they want

Chris15:10:19

@stijn Yes, that is the intent - the problem with adding it as a source root is that when, using the reloaded workflow, I do a (reset) it will detect all namespaces that have been changed and recompile them, including my repl history file, which has commands I don't want to run

Chris15:10:22

@cfleming So I do most of my coding at the REPL and as I jump between features, I have a lot of code that is specific for the features. When I used the standard REPL window with history, I would have a hard time finding REPL commands from several days ago. Now, that I've moved my REPL commands to separate files it's much easier to organize and it's also easy for me to share REPL files with team members in a way that doesn't have to be put in a source root. However, it's not straightforward on how to achieve this in Cursive. Even getting the REPL editor console separate from the output would be helpful as I'd like the editor in one pane and the RePL output in another.

Chris15:10:26

Cursive is superior for all the reasons that IntelliJ is great for Java, however the REPL support isn't very flexible in my experience from the sense of encouraging people to use the REPL

Chris15:10:23

@stijn @cfleming So far, the only way I have been able to achieve this is to use Scratch files - they have access to all the project objects and functions, are namespace aware, etc but do not get picked up by the (reset) command

marshall15:10:17

I seem to have hit an issue with the “Run with Deps” REPL I have an Environment variable for my AWS_PROFILE set and it works fine with the clojure.main & IntelliJ classpath REPL. When I switch to Run with Deps the envar appears not to be set correctly, as I’m getting auth errors against AWS APIs. @cfleming

stijn18:10:38

@chrisadegraaf you can specify refresh dirs for tools.namespace set-refresh-dirs. I don't use reloading anymore, but I remember that I solved it that way

Chris18:10:53

@stijn Thanks, I wasn't aware of that option. What do you use now?

stijn06:10:05

we try to use as much as possible just standard repl for development. if we really need to run a backend application (mostly a web api) we use (start-your-web-server #'the-handler) which gives you a web server that will always have the latest eval'ed version of your code from the repl.

stijn06:10:18

it does have some drawbacks (like renaming functions might introduce problems), but it also removes the complexity of having a 'component'-like system

Chris16:10:54

Thanks for this information, @stijn (sorry for the delayed response ) but it's much appreciated.

cfleming20:10:03

@chris547 The problem with scratch files is that they won’t be shared with your team members.

cfleming20:10:21

I do need to fix them because they’re occasionally useful, but I’m not sure they’re a great fit for this.

cfleming21:10:56

There’s another option - set up a source dir in a profile as @stijn suggests. Then you can use that profile when syncing your project to Cursive, so Cursive will set up a source root for it. But don’t use the profile when running your REPL, that way it won’t be on the classpath and tools.namespace won’t find it. Cursive will still let you execute code from it though.

Chris18:10:54

Okay, I will give this a try as well - sounds like what I want. Will report back asap.

Chris16:10:30

I think I got this to work, added a :cursive profile to my project.clj file and then enabled the cursive profile in the Leiningen settings in Cursive/IntelliJ. Thanks again!

cfleming16:10:15

Awesome, thanks for letting me know.

👍 4
cfleming21:10:23

Or possibly set-refresh-dirs might be another solution, but I’m not familiar enough with tools.namespace to know.