polylith 2023-10-16 | Slack Archive

az00:10:21

Hi everyone, wondering if there is a way to do the following. Maybe more of a tools deps question than polylith, but I think it might be easier to get an example here. I am trying to have a base that has extra-paths for dev/src and dev/resources folder under the dev alias of the base deps.edn. When I start the repl on the main polylith workspace though, I can't seem to get those extra-paths to work in any locally referenced bricks. I'm using the same structure as in the docs. This is the deps.edn for the base:

{:paths ["src" "resources"]
 :deps {ring/ring {:mvn/version "1.10.0"}}
 :aliases {:test {:extra-paths ["test"]
                  :extra-deps {}}
           :dev {:extra-paths ["dev/src" "dev/resources"]
                 :extra-deps {}}}}

Thanks

az00:10:22

I guess what I'm really asking is, can I have an alias's extra deps that point to a :local/root, also load the referenced dev alias of that dep?

jasonjckn02:10:26

That's not viable afaik

jasonjckn02:10:48

closest thing i can think of is to add those paths to workspace deps.edn "bases/foo/dev/src"

jasonjckn02:10:59

but its not a polylith design pattern

seancorfield03:10:32

Aliases are not transitive in general so an alias in a dependency (like a base) cannot be used by the project that depends on it. That's a deps limitation. The way Polylith uses :test from a brick is... An extension, shall we say. I pretty much avoid putting anything in :test in a brick now - just in projects.

az02:10:17

@U04V70XH6 it's a good point. I guess I don't have a good reason for it. Going to rethink this. Maybe somewhere in the back of my mind I thought it's better not to have systems that I hardly touch running, but what you say makes me think why not. Update the ports on the web servers to be unique locally across all the bases.

seancorfield02:10:36

Even if they're the same, you can still have one REPL -- and just start/stop each app as you work on it. They don't start automatically when you load the ns do they?

az02:10:08

az02:10:28

That's true

az02:10:03

I am starting things automatically from the user ns now, the target base I'm working on

az02:10:27

I also have common tasks like I mentioned, db tooling, seeding etc

seancorfield02:10:25

I find user.clj to be a bit of a footgun -- it's the cause of a lot of bizarre problems people come here asking for help with 🙂 What editor are you using? Maybe hotkeys/snippets are a cleaner solution...?

😅 1

seancorfield02:10:58

The development project can have src files, so those wouldn't end up in projects, only in your development REPL, and you could have project setup/teardown functions in there and perhaps snippets that did ((requiring-resolve 'dev/project-setup)) etc to invoke development/src/dev.clj's functions

💯 1

az22:10:32

Thank you @U04V70XH6 I'm going to dig back in an rethink this setup now

jasonjckn01:10:18

> "Sometimes we need to perform some test setup/teardown before and after we execute the tests for a project. If any code is used by more than one project, we can put it in a separate component," https://polylith.gitbook.io/poly/workflow/testing Would the setup & teardown go in ./components/new-component-test-deps/src or ./components/new-component-test-deps/test/src ? If its the former, bit concerned test deps are in my build, if its the latter, should I add ./components/new-component-test-deps/test/src to each project's :test alias?

jasonjckn01:10:38

I have a 'dangling' component , its not in workspace deps.edn, or projects main deps.edn, but rather its in projects test deps.edn seems to work so far

jasonjckn01:10:59

i dunno if this is kosher or not, but solves my problem.

seancorfield03:10:44

This is the correct approach (and related to my comment on the other thread).

seancorfield03:10:06

Note: if you run poly test :dev (which is rare), you might need those deps in the workspace deps.edn as well as other project deps.edn - remember that development is "just" another project.

👍 1

2023-10-16

Channels