Store project and brick configuration in separate files about polylith HOT 9 CLOSED

OK, that's fair enough. Thanks.

from polylith.

I'm also going to add a note here, reflecting the discussion on Slack that @jasonjckn and I had:

Having migrated to the new EDN file organization at work, I do not like having 20+ separate files to check for poly tool configuration (esp. the per-project aliases), and it's not a great experience in an editor that shows just the filename when you have lots of config.edn files loaded and you can't easily tell which project they belong to.

Just from an overview p.o.v., having to now consult multiple files to look at how the workspace is organized -- or being forced to run a command to get that overview -- is suboptimal.

Having the same name for all these new config files when they have different EDN schemas also feels "wrong".

Also, at work, we've renamed all the generated/migrated config.edn files to polylith.edn so that it is clear that these scattered EDN files belong to the poly tool and not some random per-project configuration/tool.

from polylith.

This change sounds cool and reasonable! It would also be great if these project.edn and brick.edn files remain open for any custom metadata (extra key-val pairs) that Polylith users are willing to add for their projects.

from polylith.

Yes, we need to figure out where custom keys/data should live. A reasonable solution could be to reserve a key, e.g. :custom, where users could put their custom data.

from polylith.

My only concern is that in large projects, you are now going from reading one EDN file at the root to potentially hundreds of EDN files spread all over the repository and that's going to have a performance hit I think...

We have ~200 deps.edn files and several operations that poly performs have definitely slowed down as our project has grown.

from polylith.

It's true that each project will get another config file, and for you @seancorfield it means 21 more files to parse. When creating a component or base, my idea is to not create a brick.edn config file. The only functionality that needs extra configuration per brick today, is when we add :ignore-files for a brick. When we need that, we will also have to create a new file. This is not so common, so I think the extra config files shouldn't be a performance problem.

from polylith.

The latest 0.2.19-SNAPSHOT release tells people to put their custom data in a :custom key @marksto-workshub.

from polylith.

The test-runner-orchestrator component will be updated, and this change will not affect external test runners.

I'll just note that this wasn't true: external test runners were broken by these changes (the changes to the internal structure were reasonable, and both existing external test runners have been updated to work with both internal formats, but more care is needed in the future, as more tools start to depend on the internal workspace data structure).

from polylith.

As I answered in the thread in slack, I think we should consider rolling parts of this back, if it makes the user experience worse. We didn't have automated tests that executed the External and Kaocha test runners, and that was why I by mistake introduced a breaking change. Now we have tests in place, that will hopefully stop it from happening again. With tests in place, I guess would not have introduced that breaking change. The reason we continue by fixing the test runners was that it had some value to support the new cleaner workspace structure, where test configuration is stored per project. It will also make it slightly easier to implement test runners in the future.
I will ask the community to see if they want to roll back the use of separate config files per project and brick.

from polylith.