This should work. You can export your workspace with poly ws out:jdhollis.edn and send it to me, and I will have a look.

What version of the poly tool do you use?

Looks like poly 0.2.18.

Thanks, will have a look.

If it helps, the specific thing that sent me down this rabbit hole is that I've specified ring-devel in my base as a dev dep. But running in the REPL using Cursive, I get a classpath error when trying to require to ring.middleware.reload.

Everything is configured per the Polylith Cursive docs. And Cursive is picking up the dev deps just fine.

Aliases in dependencies are ignored. You can't have :dev in a base or component deps.edn file.

But there's still :test?

poly specifically pulls some things from :test aliases in bricks but that's not how the CLI/`tools.deps` works in general.

Got it.

That's what I figured from the docs.

At least upon re-reading.

For something like ring-devel, I would put it in the workspace deps.edn under the :dev alias for REPL usage.

(well, personally, I would never use ring-devel or any similar reloading/refreshing library)

I've been avoiding it up until now, but I've been testing some handler changes. Thought I might try to save myself some extra evals.

I eval every change I make in my editor, into the running REPL. No reload/refresh needed.

(also, with my admin hat on, can you please use threads in future instead of multiple top-level posts -- and that applies in pretty much all channels here)

A single top-level post, with details in a thread, makes it much easier for people to a) follow a single discussion and b) be able to have multiple conversation active in a single channel without them overlapping each other.

Will do.

Eh. In this case, I just need to use integrant/repl. Which I can add to my top-level :dev alias.

Thanks!

As far as the thinking behind this... In my understanding Whether something uses ring-devel or not is a deploy-time (aka project-level) decision. When you deploy this app somewhere, you define its deps (Without ring-devel) in its project/project-name brick, so the decision to include ring-devel or not should be considered the same. This is why "development" is for all purposes a project, it just gets activated with the :dev alias at the root deps.edn. So using anything like ring-devel, or a system.edn (for integrant) with some dev IAM keys and so on.. also happens with the development project.

(I wrote and rewrote parts of this reply in between other tasks, so hopefully it makes sense)

It's the same btw with other deps, like integrant.repl -- that would be defined in your dev alias, and not in individual components or bases making use of (go) etc

I have honestly held back on trying 0.2.19 because of this -- mostly because I don't want to have to update my understanding of polylith in the middle of a big project and some other life events. I was hesitant exactly of what you said - spreading the workspace config in multiple files/bricks. Feedback from people who have actually tried 0.2.19 should be given more weight, of course.

I've had a good nights sleep, and I just decided to rollback how we store project and brick configuration in workspace.edn, but to keep the changes in the internal workspace structure. I have other thought also, but will post them separately.