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?

My poly version is 0.2.14-alpha (2022-03-30), and I'm still seeing this error.

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.

Email sent, please let me know if you need any additional information

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

https://github.com/polyfy/polylith/issues/208

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.

I was referring to your comment that you have migrations for dev, to setup tests

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.

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.

Thanks for checking, Sean!

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"}
...

: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?

Clojure 1.10.3, nrepl 0.9.0 and cider-nrepl 0.28.3

None of that is the Clojure CLI

clojure -version is what I'm asking about

Ah, quite right, Clojure CLI version 1.10.3.839

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

Heh, bad luck / timing. We moved to polylith last summer

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)