This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (112)
- # announcements (6)
- # beginners (197)
- # boot (3)
- # calva (52)
- # cider (25)
- # clara (14)
- # cljdoc (6)
- # clojure (147)
- # clojure-austin (6)
- # clojure-berlin (7)
- # clojure-brasil (2)
- # clojure-europe (3)
- # clojure-india (4)
- # clojure-italy (8)
- # clojure-new-zealand (2)
- # clojure-nl (7)
- # clojure-russia (7)
- # clojure-spec (29)
- # clojure-uk (63)
- # clojurescript (103)
- # core-async (5)
- # cursive (11)
- # datomic (16)
- # devcards (1)
- # emacs (28)
- # figwheel-main (3)
- # fulcro (97)
- # graphql (4)
- # hyperfiddle (1)
- # jobs (1)
- # kaocha (3)
- # lumo (9)
- # nrepl (4)
- # off-topic (29)
- # onyx (1)
- # pathom (4)
- # pedestal (8)
- # re-frame (24)
- # reagent (1)
- # reitit (13)
- # ring-swagger (6)
- # rum (11)
- # shadow-cljs (79)
- # sql (46)
- # tools-deps (67)
- # yada (8)
anyone got any pointers for using clj/deps.edn on a multi-module monorepo ? we currently use
lein-modules with a top-level
project.clj with common dependencies and module level
project.cljs in sub-directories - i'd ideally like to be able to do something similar
I’ve not actually done this yet @mccraigmccraig but
:local/root is the answer you probably already know… More specifically it might be worth looking at juxt edge as I think @dominicm has been doing stuff in this area in that repo.
Also ask in #tools-deps
hmm - not sure about
:local/root - we currently use
:source-paths in lein for something similar, but only in the
:dev profile for easy cross-module c.t.n.repl refreshes - for test and release i would like strict inter-module dependency DAG enforcement. but #tools-deps seems like the place to go...
@dominicm do you have any examples in that repo where a
main is also a published artifact?
also a published artifact? Nope. But there's no reason anything in there couldn't be.
@dominicm: I see you’re also using integrant :thumbsup: One thing that has been on my mind for a while is how tools.deps and integrant interact, and how components are related to their dependencies. I’ve thought for a long time that integrant is close to the perfect clojure module system and all it’s missing is the connection to dependencies, which tools.deps brings. It feels like there’s a missing piece somewhere here, and how you’ve noticed this same thing too in the divisions within juxt. What are your thoughts on this? 🙂 And what are the criteria you use to lift something out into a tools.deps module? Is it just sharedness (or expected sharedness) with other apps in the repo or something more?
I remember someone having the brief idea to tie components to dependencies, and you could do it, but I think losing the static declaration might be a cost you don't want to pay. Although you could generate the deps.edn from the config.edn in edge, as we make the system more static. So there's that. Ultimately, it's no more tied than namespaces are to dependencies. I think you would solve those 2 problems together (as rich hinted at a couple years ago, with his "because Fred told you").
Splitting out a module? Well, I was hoping our previous discussion would drive some stronger thoughts on this. But currently it's about expected or real re-use.
I am very pleased to announce my new Heckling-as-a-Service... also known as HAAS. @jasonbell will get a special discount.
we use something not dissimilar to integrant if you squint askance (with async support for cljs) @rickmoynihan components are sometimes equivalent to modules (we have modules for largish things like cassandra, async, core-model, ui-core, api, stream, webui etc), but often much finer grained. things get lifted to modules generally when they exist as a "thing" which needs to be shared amongst multiple other modules. sometimes modules correspond 1-1 to components (cassandra does), sometimes they don't have any components (async) and sometimes they contain many components (core-model)
@mccraigmccraig: That’s close to how I see it too… though I think there’s also a distinction between modules/components and libraries that’s worth decomplecting:
- A component is typically a stateful thing, a process. It may have configuration and defaults. They either bring their own state, or depend on other stateful components. It may have library dependencies too.
- A library is a reusable dependency that doesn’t bring any real state to the party. It has no coupling to components.
- A module is a reusable component exposed as a dep/artifact
Either libraries or modules could be
:local/roots in tools.deps (as it doesn’t care)
we're similar - although some of our libs define components (generally as protocols with instances to be built by our app-context builder) and component constructor fns
deps.edn doesn't have pedantic abort, and it makes much less sense in deps.edn too. Because it always picks the newest version.
picking the latest version would have been way more sensible for lein... 99% of my resolutions are exclude the earlier version
Hi, do any of you have any experience with MetaTrader ? It’s a trading platform: https://www.metatrader5.com/en I have a bunch of questions for you if you do. Thanks
Basically MetaTrader is a platform that is a client and a server. All the API wrappers that I’ve seen for it need to mind meld with MetaTrader’s DLL to be able to tap into it.
There were some attempts around 8 years ago to get some sort of a wrapper in Clojure, but it hasn’t been touched since.
So I was hoping that there might be some Java API wrappers… and maybe somebody here who has used it. 🙂
@dotemacs having a quick read it looks like you can directly talk to the system as long as you have it running
https://stackoverflow.com/questions/39592718/how-to-send-receive-data-to-from-metatrader-ternminal-4-with-java-or-anything The language used is a bit strange
I was really hoping that somebody here had some experience with this already so that I could talk to them.
Some example code in node (tiny) to push whatever’s sent to it into the running terminal: https://github.com/PenguinTraders/MT4-Node.js
The github repo does look pretty readable though, so might be a good basis for experiments if you’ve already got yourself setup :)… Sorry I couldn’t help.