juxt

dominicm 2017-03-08T09:00:03.000085Z

https://github.com/juxt/joplin/pull/97 Whilst I don't think joplin should really have load-string in the first place, and is clearly a commonality to aero. I don't think aero should become a dependency. Any reason you can't use aero to load a config (bypass joplin load string) and then pass that map to the functions?

jonpither 2017-03-08T09:53:21.000086Z

@otfrom ^

acron 2017-03-08T10:25:24.000087Z

@dominicm No reason whatsoever, just thought it might be a nicer alternative to use aero, and there was a PR made to aero to add 'envf' so that the port would be compatible. But yeah, this is an opinionated PR. Discuss/reject at will 🙂

acron 2017-03-08T10:27:18.000088Z

@dominicm If you're looking at PRs, https://github.com/juxt/joplin/pull/98 is keeping us on a fork at the moment and there'll be a follow-up PR which adds some additional configuration to joplin.dynamodb

dominicm 2017-03-08T10:28:26.000089Z

@acron I have no idea about DyanmoDB generally 🙃 But I see no reason to bump that. Your configurable table name looked good too.

acron 2017-03-08T10:28:42.000090Z

🙂

dominicm 2017-03-08T10:30:20.000091Z

RE Aero, concerned that it will basically end up with classpath collisions & exclusions for most people. Aero still has the occasional breaking change added. For example there's some recent discussion about preferring #aero/ref #aero/join #aero/env as the default. I think my design preferences differ from the original authoring of Joplin, I've always found it awkard that it had it's own configuration. That's possibly by design though (that I'm not seeing)

acron 2017-03-08T10:32:55.000093Z

@dominicm That makes total sense. I am happy to close the PR. With your design preferences in mind perhaps the inverse would be a good idea then; removing the load-config function entirely and encourage people to use their own configuration solution (which could be Aero if they like).

dominicm 2017-03-08T10:33:53.000094Z

@acron My only questionmark over that is whether joplin is this way because of something like lein-joplin.

acron 2017-03-08T10:34:12.000095Z

@dominicm Yes, I suspect that's probably the kink in that plan

acron 2017-03-08T10:34:33.000096Z

Also, the aliases concept becomes a bit harder

acron 2017-03-08T10:34:48.000097Z

lein seed, lein migrate etc

acron 2017-03-08T10:35:51.000098Z

(That might be what you're referring to by lein-joplin)

dominicm 2017-03-08T10:35:54.000099Z

@acron Yeah. I think on projects I've been on, our migration process was: 1) lein repl 2) (migrate-and-seed :local) (a helper)

dominicm 2017-03-08T10:36:05.000100Z

So we didn't really run into that.

acron 2017-03-08T10:36:30.000101Z

@dominicm Our use case is similar

dominicm 2017-03-08T10:39:22.000102Z

@acron Hadn't realised that lein-joplin was deprecated… that makes this much easier then imo. Want to use your own migrate-and-seed? New aliases!

dominicm 2017-03-08T10:41:22.000103Z

lein run -m app.joplin.alias/migrate is your new alias I would suppose.

acron 2017-03-08T10:42:54.000104Z

@dominicm aliases.clj uses load-config so that'd need some thought: https://github.com/juxt/joplin/blob/master/joplin.core/src/joplin/alias.clj

dominicm 2017-03-08T10:43:47.000105Z

@acron I think I'd just deprecate the function (never remove it, Hickey–style), no?

acron 2017-03-08T10:44:05.000106Z

@dominicm works for me

2017-03-08T10:54:18.000107Z

jonpither thx for calling me. As you can see I nudged the affected parties. 😄

👍 1
acron 2017-03-08T16:11:47.000109Z

@dominicm Anything else we need to do to get this merged? 😉 https://github.com/juxt/joplin/pull/98

acron 2017-03-08T16:13:41.000112Z

Or did you wanna talk about Faraday 1.9.0 ?

dominicm 2017-03-08T16:19:14.000114Z

@jonpither who's clicking buttons and doing releases?

jonpither 2017-03-08T16:43:15.000115Z

Thatd be you :-)