Tests are run per-project -- are you talking about the :test alias in projects/*/deps.edn?

Also, where exactly is your env folder?

The env folder is in the workspace root. There's a env.clj that changes depending on the environment it's running in (mainly for things like middleware, auth, etc). It sits under env/dev/clj/env.clj env/test/clj/env.clj env/prod/clj/env.clj

So when it's running from clj -A:dev it will use the env/dev/clj in its paths

Is this something you're going to be reusing across multiple projects or will each project have a unique "prod" env.clj file?

It's purely an environment thing, I'm happy to replace it just not sure the best way to do it

(`development` is also a "project", with assets brought in via :dev)

"It's purely an environment thing" -- that doesn't really say anything about what it is or is used for.

Hence: Is this something you're going to be reusing across multiple projects or will each project have a unique "prod" env.clj file?

Ah I see. Re-using across multiple projects

Because Polylith forces you to think about separating projects -- how things are built (and tested) -- from bases -- application code, you might have to think a bit differently about this.

Actually, I've delved into it a bit more. The prod & test env.clj files are basically the same, so maybe the original question is moot. I'll go read a bit more into bases, that might be exactly what I'm after

Thanks so much for your time ❤️

If you have a single filename -- env.clj -- then it's likely you may have to have one per project (and one for development) but that makes selecting a different one for :test rather difficult.

At one point env.clj was different between test and prod, but we fixed how the tests work so we didn't need it anymore

(I don't like separate environment code for a lot of reasons -- and this touches on some of those reasons)

We have our configuration in EDN files that are in a configuration directory, separate from the repo.

The main workhorse is in a dev environment - adding hot reload middleware and init commands

So at a rough glance, using one base for dev and another for prod looks to be exactly what I'm after?

No, bases are not projects

"development" is a project, and each buildable/testable artifact is a project.

But in the development project, I can use a base with the development init things. And in prod I can use a base without all the extra dev stuff? Or am I misunderstanding bases and need to have another read?

No. development itself should hold dev-only code.

The project itself should be the only one holding the code?

Each (non-`development`) project typically has one base, that contains the entry point for that application. A project defines how an application is built (and tested). The :dev alias and development project determines what your REPL experience is like.

projects generally don't contain any code, although they can ... but typically only contain code to support the building of each separate project/application. The application code itself lives in a base.

I guess I'd be a bit surprised that env.clj would be identical across all of your projects since it is environment-related: I'd expect the environment config to be at least slightly different between projects...

Right now it's still definitely one project (plus dev), it's just trying to think how to migrate previous assumptions over

That's why I thought maybe a dev version of env.clj in development/src and then the project-specific "prod" version in projects/*/src for each project (given that your testing env.clj is the same as your production env.clj).

(you might start out with an identical src/env.clj file in each of your projects/* folders but maybe they'll diverge over time?)

And then development/src/env.clj will be your REPL experience version, brought in via :dev

I believe this is a convention from luminus and kit-clj https://kit-clj.github.io/docs/guestbook.html#the_env_directory

What I have been doing is using a component I created called called config which uses aero with defaults for dev, I then modify the config using env in testing and deployment no idea on if this is a good strategy but works quite well for me as usually its thing like the db or api's that change, I also have some helper functions to allow me modify the config in development.

We're moving existing services that follow a similar creation template into PL. The service template created > 100 services. My instinct is to mirror the service template as a base, and - to keep the flexibility with the product teams - leave the composition (component/mount etc) in the project. Are there reasons not to do that? Code in the project does not seem like a common PL pattern.