Allow different reporters via leiningen profiles

[katox]

Currently the configuration is read from a resource-path. It's a fixed location, single file eval. I'd like to have a different test *reporters* set in different lein profiles so I can run commands such as:

lein with-profile +junit test

while running it without it by default.

I can modify the project.clj to set different resource-paths for different profiles just for circleci.test/config.clj but I can't do it for existing projects with no modification (using .lein/profile.d/ for instance).

[technomancy]

It's not a great solution, but since the config file is executed, not just read, it's possible for a profile to provide a config file which will read the original shadowed config file and assoc its own changes into the data it finds there.

[katox]

If it's always guaranteed that +profile is first on resource classpath it can be used as a workaround.

But I don't get why an eval is preferable. A data structure would be much simpler to handle. What is the use case?

[technomancy]

If it's always guaranteed that +profile is first on resource classpath it can be used as a workaround.

Yes, this is guaranteed.

Loading a file is preferable exactly because it allows things like this. You can just make the file contain a data structure if that's what you want, but you aren't limited to that.

[katox]

It works. But only if the resource file is directly referenced by resource-paths. It can't be put in a jar that's added into profile dependencies. Otherwise it would it would be shadowed by project's own circleci_test/config.clj (and it makes sense).

Instead of writing a plugin (or a hook) that would copy the circleci_test config somewhere into target/ I ended up with

{ :resource-paths #=(eval [(str (System/getProperty "user.home") 
                                                 "/.lein/profiles.d/myprofile-resources")]) }

in .lein/profile.d/myprofile.clj + .lein/profiles.d/myprofile-resources/circleci_test/config.clj.

I don't do classloader lookup, eval and merge because most of the time I can just replace the config. Fortunately I can still override the profile in the project if fancy merging was needed. Even though that needs a change to the project I expect such cases to be rare.