1. I don't even know what :: is/was so I guess I won't miss that 🙂 2. I agree that supporting both the short and long create commands seems pointless, esp. with auto-complete in the shell 3a. test-all forces :all to be added but the underlying test function isn't exposed in the API -- why not? It's there in the test.clj implementation, and it's what I'd prefer to use: (api/test "stable" :all) should work and be equivalent to (api/test-all "stable") -- note :all keyword, not ":all" string, so have the underlying implementations (map str args) for convenience 3b. Fix this warning: WARNING: test already refers to: #'clojure.core/test in namespace: polylith.clj.core.api.test, being replaced by: #'polylith.clj.core.api.test/test -- add :refer-clojure :exclude [test] to the files that define test 4. I'm surprised that check takes since as an argument -- the poly check command doesn't seem to take any arguments? What does check since:release even mean? 5. since could be optional in all cases and default to "stable"

(clarifying 3a -- we pretty much never use test :all, just test (since stable) and test since:release)

1. I never use it either! 2. I agree, and if you don't start a shell, it's still not very time-saving, since you don't create bricks, projects, and workspaces very often. 3. a. Yes, let's change to test instead as you suggest. I implemented it this way first, but thought everyone added :all anyway in their CI-build, because if we don't give :project or :all then the project tests will not be executed. When I think about it, passing in :project can make more sense, because then you get an incremental build that includes the project tests. :all will run everything. But this is up to the user of the API, and if we expose test instead of test-all then we give maximal flexibility to the user of the API. You are right that the user can pass in a keyword, which looks cleaner. I will change. b. I will fix. 4. Looks like a mistake by me (I reused a function that retrieved the workspace). No, since doesn't affect the check command. Will fix. 5. Yes, I have thought about this too. It would be possible to pass in e.g. since:release as an argument, together with the other arguments. Let's do that change, and see if we get any other feedback here. > clarifying 3a You need to give :project (or :all) to include project tests, and that's what you want in the CI-build, but not every time when developing.

3a. Part of what makes CI better for us is the incremental testing since:release (since every master build gets tagged with a release)

Locally, we just run test (i.e., since:stable) and let it run whatever has changed since we last tagged local dev, in CI we run test since:release. And we use (projects-to-deploy "previous-release") to determine what JAR files to build -- we do test since:release then tag master with a release then figure out what to deploy (so the previous-release at that point is what release was at the start of CI).

BTW, I already updated work to the new snapshot so I could get rid of the earlier calls to user-input and command 🙂

It's always nice when you can clean up the code a bit and reduce unnecessary complexity. Does this mean that you don't have tests at the project level, or is it that you just skip them in the CI build?

https://cljdoc.org/d/polylith/clj-poly/0.2.19-SNAPSHOT/api/polylith.clj.core.api.interface#test is deployed.

Just to clarify, if we ever add per-`project` test files, we would need to call projects-to-deploy and then explicitly pass (str "project:" (str/join ":" changed-projects)) to test in order to get those tests to be run, in addition to any regular base/component tests? I sort of expected that to be automatically computed by poly, since it would know those test files existed...

If you give the same since, e.g. since:release and :project it will calculate the same list of changed projects and also include them in the tests.

The plan right now is to use polylith.edn as the root config file when we add support for https://github.com/polyfy/polylith/issues/431 that I plan to do next. You could consider something different, like entity.edn but polylith.edn should also work.

It's possible now to give config-filename when you https://cljdoc.org/d/polylith/clj-poly/0.2.19-SNAPSHOT/doc/reference/commands#migrate a workspace.

Both are pretty generic , perhaps polylith.edn or something with the word ‘poly’ eg. entity.poly.edn

workspace.entity.edn

But if config.edn works for, let's say, 90% of the users, then maybe that's okay. An alternative could be entity-config.edn .

I don't like "entity" and I don't think the poly docs use that term? Besides, "entity" is more associated with a domain-level component than a project or base so I think it implies the wrong level of granularity. At work, I've switched to polylith.edn so it is obvious these EDN files belong to Polylith rather than being some project-specific "config" and, at least right now, we only have them in the projects/*/folders (and development). I think polylith.edn would be a better default, but I don't feel strongly about it. If you could easily have different names in different parts of the workspace, I'd say use poly-base.edn, poly-component.edn, and poly-project.edn -- or poly-brick.edn and poly-project.edn -- since the project EDN files are going to be quite different from the brick EDN files.

My original idea was to name them base.edn , component.edn , and project.edn . Don't you think that naming convention would be unique enough? If not, we could support :config-filename with the map {:prefix "", :suffix ""} in workspace.edn, and then people could add poly- as prefix and/or -config as suffix (or something else) if needed. But I would prefer to keep it simple, and only support base.edn, component.edn and project.edn if possible, especially if the naming doesn't clash with other tooling.

base/component/project is fine with me but definitely the more control the better either over prefix /suffix or just being able name everything individually

Project.edn , etc are all very generic and prime real estate I don’t know of any conflicts as of today but it’s very close to project clj

+1 for no ‘entity’ per Sean reasons

I still need to dive deeper into your changes, I’ll spend some time on that soon, but from afar I would wonder why either (1) you don’t have everything inside workspace.edn like a map with keys and one key for each workspace folder or (2) why there isn’t a single filename like ‘deps.edn’ which supports nesting and may appear at subdirectory levels as well as root But that’ll probably become more clear to me after I get up to speed to apologies.

Re: (1) I will also say that I've really no idea why this change was made -- looking at one file workspace.edn with all the config in is much easier than now having to look in 20 files to figure out how to use poly (what project aliases are available). I mean, I'm sure you have good reasons but the change is definitely detrimental for our very large workspace.

(I'm re-reading #315 and the only real justification I can see is to make it easier somehow to support cljs as well as clj)

Also, it would be really nice if the next-release.txt file was Markdown so issues and PRs in it worked as links to the actual URLs on GitHub.

All project config can be viewed with ws get:configs:projects if that helps.

I want to see the full config in my editor in a single file.

I should not have to run a command to reconstitute that info.

(when I originally read issue #315 I didn't think it was too problematic, but now I've migrated my workspace to 0.2.19, I really don't like it)

It just seems a bit clunky to have multiple different edn schemas spread over a file system , at least when deps edn does it , it’s the same schema for all

Although I did express concern that we might end up with 200+ config files since we have so many bricks at work.

I agree that having the same-named EDN file in multiple locations with different schemas is a bad idea as well.

In emacs that’s 200x buffers named config.edn<N> 😂

It isn't great in VS Code either, although it does at least show the file path when a particular file has focus, and when you switch between editors it shows the file path too.

I've attempted to summarize this discussion into https://github.com/polyfy/polylith/issues/315 so it isn't lost.

Putting project configuration in workspace.edn under :projects and brick config under :bricks is still supported by the poly tool, and my plan is to keep it that way, so that the tool can read old workspace formats (it supports all old formats). You can try to move back your project config into workspace.edn if you prefer that. The idea was not to reduce the user experience! If most people think storing config files in separate files was a bad idea, then we should consider rolling that back, but if enough people think it was a good ide, then we could support both behaviors (then this could be configurable in workspace.edn, so that you don't get a warning that the workspace is not migrated).

Having migrated to the new structure, I would definitely prefer to "migrate back" and tell poly that I prefer the single-file config. So thank you for being open to that. If there are specific reasons for per-project EDN files -- and down the line, per-brick EDN files -- I'm interesting in discussing that but nothing I've read in that issue convinces me of that yet. I feel like the "multiple workspaces" and "multiple languages" arguments are still too nebulous to be actionable...

I'd be ok with supporting both, failing that, rollback if you support both, try to find a simple/composable mechanism for that, e.g. aero's #include syntax in EDN is one example of simplicity, but may or may not be ideal here. Also, i'd suggest 1 unique filename per EDN schema, wherever we land, with fewest number of schemas possible.

I wanted to move project and brick configuration in the internal workspace structure to where they belong, as a way to reduce complexity and to clean upp things. I also had the idea that it made sense to also store each config where they belong on disk. I didn't realize (and no one else I think) that this could make the UX worse. It did sound reasonable, but this is how software works, you sometimes need to build things to get that feedback. I don't want to introduce functionality that makes the user experience worse, so we should reconsider rolling parts of it back (the use of separate config files) but keep the change in the workspace structure. I think supporting both separate config files, and keys in workspace.edn, will add extra complexity, which I don't like. It's better if we have one way of configuring things.

I agree that the internal structure changes are positive (despite that breaking both test runners 🙂 ) but, yeah, now we have experience with it, a single workspace.edn file seems a better UX.

I wrote a reply in https://github.com/polyfy/polylith/issues/315.