This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-07
Channels
- # announcements (5)
- # asami (17)
- # aws (11)
- # babashka (67)
- # beginners (90)
- # calva (13)
- # cider (17)
- # circleci (6)
- # clj-kondo (3)
- # clojure (53)
- # clojure-europe (12)
- # clojure-france (8)
- # clojure-germany (3)
- # clojure-losangeles (1)
- # clojure-nl (4)
- # clojure-norway (4)
- # clojure-spec (15)
- # clojure-uk (8)
- # clojurescript (41)
- # cursive (7)
- # data-science (6)
- # datomic (8)
- # emacs (10)
- # exercism (1)
- # figwheel-main (2)
- # fulcro (5)
- # graalvm-mobile (97)
- # graphql (1)
- # hyperfiddle (7)
- # inf-clojure (6)
- # interop (4)
- # introduce-yourself (5)
- # jobs (3)
- # kaocha (3)
- # malli (8)
- # meander (8)
- # music (3)
- # nrepl (7)
- # observability (1)
- # off-topic (45)
- # overtone (2)
- # polylith (63)
- # portal (2)
- # re-frame (26)
- # reveal (8)
- # ring (3)
- # shadow-cljs (56)
- # tools-build (5)
- # vim (11)
- # xtdb (8)
I'm porting a library into a polylith component. When I try to run the tests with poly test :dev
, I get an exception:
java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at polylith.clj.core.common.class_loader$invoke_in_STAR_.invokeStatic(class_loader.clj:31)
at polylith.clj.core.common.class_loader$eval_in_STAR_$print_read_eval__233.invoke(class_loader.clj:46)
at polylith.clj.core.common.class_loader$eval_in_STAR_.invokeStatic(class_loader.clj:51)
at polylith.clj.core.common.class_loader$eval_in.invokeStatic(class_loader.clj:60)
at polylith.clj.core.common.interface$eval_in.invokeStatic(interface.clj:21)
at polylith.clj.core.test_runner.core$run_test_statements$fn__7491.invoke(core.clj:63)
at polylith.clj.core.test_runner.core$run_test_statements.invokeStatic(core.clj:63)
at polylith.clj.core.test_runner.core$run_tests_for_project.invokeStatic(core.clj:121)
at polylith.clj.core.test_runner.core$run.invokeStatic(core.clj:171)
at polylith.clj.core.test_runner.interface$run.invokeStatic(interface.clj:4)
at polylith.clj.core.command.test$run.invokeStatic(test.clj:9)
at polylith.clj.core.command.core$execute.invokeStatic(core.clj:75)
at polylith.clj.core.command.interface$execute_command.invokeStatic(interface.clj:4)
at polylith.clj.core.poly_cli.core$_main.invokeStatic(core.clj:31)
at polylith.clj.core.poly_cli.core$_main.doInvoke(core.clj:7)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at polylith.clj.core.poly_cli.core.main(Unknown Source)
Caused by: Syntax error compiling quote at (0:0).
Wrong number of args (0) passed to quote
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7119)
at clojure.lang.Compiler.analyze(Compiler.java:6793)
at clojure.lang.Compiler.analyze(Compiler.java:6749)
at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3892)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7113)
at clojure.lang.Compiler.analyze(Compiler.java:6793)
at clojure.lang.Compiler.analyze(Compiler.java:6749)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6124)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5471)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:4033)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7109)
at clojure.lang.Compiler.analyze(Compiler.java:6793)
at clojure.lang.Compiler.eval(Compiler.java:7178)
at clojure.lang.Compiler.eval(Compiler.java:7170)
at clojure.lang.Compiler.eval(Compiler.java:7136)
at clojure.core$eval.invokeStatic(core.clj:3202)
at clojure.core$eval.invoke(core.clj:3198)
at clojure.core$eval138.invokeStatic(NO_SOURCE_FILE:0)
at clojure.core$eval138.invoke(NO_SOURCE_FILE)
at clojure.lang.Compiler.eval(Compiler.java:7181)
at clojure.lang.Compiler.eval(Compiler.java:7136)
... 21 more
Caused by: clojure.lang.ExceptionInfo: Wrong number of args (0) passed to quote {:form (quote)}
at clojure.lang.Compiler$ConstantExpr$Parser.parse(Compiler.java:2008)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:7111)
... 41 more
Couldn't run test statement for the development project: (do (clojure.core/use (quote clojure.test)) (clojure.core/require (quote )) (clojure.test/run-tests (quote ))) java.lang.reflect.InvocationTargetException
What version of the poly
tool are you using @U028BUU1P3R?
From that test statement
line, it looks like it can't determine the correct name of one of your namespaces to be tested...?
Do you still have problems with this @U028BUU1P3R?
Run poly ws out:winsome.edn
at the workspace root, and mail me the output together with ./deps.edn
and ./workspace.edn
and I will have a look.
Please do report back with the source of the problem -- I'm really curious about this error 🙂
We found the problem. @U028BUU1P3R will reply here when he has created an issue!
I've started putting together a minimal reproduction, should be finished by lunchtime
How do you handle db migrations in polylith? Migrations are quite often in a separate, global place, but that runs counter to the idea of distinct components handling their own thing.
We have a migration
project which depends on a handful of components that deal with database stuff and a base that has the main CLI for our migrations. Then we can either build the migration
JAR (which is how we auto-deploy migrations to QA and production) or run it locally via our build.clj
script.
Hm, I'm used to systems that check at startup time that the db is in the expected state and runs migrations if needed (with migratus).
But of course those systems have been tightly coupled monoliths with the db, with no pluggable components at all
Not that it is material, but this time we are not using plain SQL but xtdb instead, so we wouldn't be using migratus exactly anyway
Well, our build.clj
script runs migrations then tests (and has a "cold start" mode to tear everything down and run migrations from scratch -- which we use in CI). But for general development, the DB is pretty stable so running migrations manually is fine.
We deploy our migration
JAR separately, ahead of others, if we need to apply migrations (and so we also make sure our migrations work for both existing code and the code about to be deployed).
(and our auto-deploy services check for migration
first and run it before they auto-deploy & restart any other services)
Do you have a global db, or does the set of migrations somehow depend on the env/system that you are deploying?
I'm thinking if I would just put everything in a db component, and have that deal with the migrations, then all the components would query their data from there, if at all. Would make the db a bit of a monolith, but at least contained
We have a separate MySQL setup for each tier (local dev, CI, QA/staging, and a cluster in production). The migrations for "dev" run on dev and CI, all other migrations run on all four tiers. The "dev" migrations are usually to set up test data. We have about 900 migrations at this point.
The actual migrations are in .sql
files that are loaded and run by the migrations
brick. Plus it also has a number of programmatic "data migrations" which run automatically in dev/CI but which we have run manually as one-offs on QA and on production -- often stuff like computing new values for recently-added columns, or backfilling new tables as we evolve the schema.
How do you handle choosing the right migrations? Sounds like you have just one migrations component, not one for every env. Do you just include all of them and choose based on env, or a config file, or do you have the migrations in a separate place and package them with the deployments?
I'm not sure I understand your question. Why would you want different migrations between QA and production? That sounds like a recipe for disaster to me.
Right, we have some migrations that only apply to dev/CI. They have dev
in their name, right after the migration number. 0200_foo.sql, 0201dev_bar.sql, 0202_quux.sql.
We used them a lot more early on, setting up bulk test data, but we rarely use them now, preferring to have test fixtures set stuff up as needed.
Hi everyone! @imre did a great progress with the PR mentioned below. It would be nice if you could try it out and report if anything fails in your projects. If you want to, you could also try the new pluggable test runner option with the https://github.com/imrekoszo/polylith-kaocha implementation.
I have used kaocha before, and am using polylith now, but not yet together so it's great to see progress though it probably won't be this month yet we would be testing the combination
I just switched to the PR version at work and it still runs our tests (with the Cognitect runner) just fine -- so it doesn't seem to have broken anything on the default path.
Hello! I've been migrating my codebase to Polylith and really appreciate the design. However, I think I may be getting tripped up by the Cursive/non-Cursive set up. I don't use Cursive. I have a development deps.edn
{:aliases {:dev {:extra-deps {poly/mybase {:local/root "./bases/mybase"}}
but non of the mybase deps.edn
settings are loaded with
clj -A:dev
Any ideas? All of the examples seem to be using the Cursive workaround.What do you mean by "mybase deps.edn
settings"?
(we don't use Cursive at work and we specify our :dev
dependencies via :extra-deps
and :local/root
and it works "as expected")
Note: we use :local/root "bases/mybase"
at work -- without ./
The start of our :dev
alias:
:dev ; Polylith "everything"
{:extra-deps {;; bases
poly/activator-cli {:local/root "bases/activator-cli"}
poly/admin {:local/root "bases/admin"}
poly/artifact-uploader-cli {:local/root "bases/artifact-uploader-cli"}
poly/auth {:local/root "bases/auth"}
poly/batch-jobs {:local/root "bases/batch-jobs"}
poly/eros-features-cli {:local/root "bases/eros-features-cli"}
poly/frankieee-cli {:local/root "bases/frankieee-cli"}
poly/login {:local/root "bases/login"}
poly/preview-web {:local/root "bases/preview-web"}
poly/seo {:local/root "bases/seo"}
poly/system {:local/root "bases/system"}
;; components
poly/activator {:local/root "components/activator"}
poly/affiliate-link {:local/root "components/affiliate-link"}
poly/appstoreconnect {:local/root "components/appstoreconnect"}
...
and the start of our :test
alias:
:test ; Polylith's testing context for the development project
{:extra-deps {worldsingles/worldsingles-test {:local/root "worldsingles-test"}
com.github.seancorfield/expectations {:mvn/version "2.0.160"}
org.clojure/test.check {:mvn/version "1.1.1"}}
;; Polylith "workspace test deps"
:extra-paths ["bases/activator-cli/test"
"bases/admin/test"
"bases/auth/test"
"bases/artifact-uploader-cli/test"
"bases/batch-jobs/test"
"bases/eros-features-cli/test"
"bases/frankieee-cli/test"
"bases/login/test"
"bases/preview-web/test"
"bases/seo/test"
"bases/system/test"
"components/activator/test"
"components/affiliate-link/test"
@URMJAL866 Do you get any errors? What makes you think "settings" are not loaded?
That's my setup as well. In your example above, if poly/activator-cli
has its own deps.edn
file with an alias :dev
that, in turn, defines :extra-paths
, shouldn't they all be merged together when launching clj -A:dev
?
Ah, no, you can't have :dev
aliases in bricks' deps.edn
files.
That's just a Clojure CLI / tools.deps.alpha
restriction: aliases are not transitive.
Aha! That I did not know. Thank you! So keep all of the aliases at the top level.
(For development)
Aliases are only active for the "project" deps.edn
file -- in Polylith's case, that's the workspace-level file. When it runs tests, it programmatically pulls in stuff from the :test
alias of bricks' deps.edn
but that's poly
behavior, not t.d.a/CLI behavior.
Our activator-cli
base deps.edn
:
{:paths ["src"]
:deps {worldsingles/worldsingles {:local/root "../../worldsingles"}
com.github.seancorfield/next.jdbc {:mvn/version "1.2.780"}
com.stuartsierra/component {:mvn/version "1.1.0"}
org.clojure/tools.logging {:mvn/version "1.2.4"}}
:aliases {:test {:extra-paths ["test"]
:extra-deps {}}}}
:test
only works there because of what poly test
does.
Thank you for the clarification. It was driving me mad 🙂
(and worldsingles
is a legacy non-brick subproject -- as we're still working through our refactoring)
Feel free to reach out via DM any time with Polylith migration Qs if you're seeing something odd 🙂
Much appreciated, @U04V70XH6.
Also, I never see new deps loaded before nuking .cpcache, but sounds like that wasn't your case
You should never need to nuke that cache these days - what CLI version are you using?
None of that is the Clojure CLI
clojure -version
is what I'm asking about
Yikes, that's a year old! The local deps cache issue was resolved maybe six months ago. You need to keep the CLI updated.
There have also been huge functionality improvements since .839
We vendor the CLI into our repo and deploy it automatically across all our servers so every dev and every server has the same version available. We rely heavily on all the build.clj
stuff that came in .933 and several of the bug fixes from later versions.
(sean)-(jobs:0)-(/Developer/workspace/wsmain/build)
(! 835)-> clojure/bin/clojure -version
Clojure CLI version 1.11.1.1105
(that's dev-only right now -- production has clojureCLI Clojure CLI version 1.11.0.1097
which is essentially identical, except for the change from 1.11.0 to 1.11.1 as the default but we always specify the Clojure version in deps.edn
everywhere)