tl;dr below.
This just has been such a huge “facepalm head-desk” moment for me after updating addressables to 1.16.6.
Here’s a little story.
I was really exited to see
- Added detailed build layout feature. See documentation for details.
in the changelog! Finally, more data to analyze how/why builds are laid out the way they are!
I updated the package, got into the Project Settings and set the checkmark for the build layout report.
I tried to commit the changed project settings into our VCS. But - no changed files! I saved the project, closed the editor… still no changed files. “Where is this setting stored?” shot through my mind.
I started my journey through the addressables source, just to find…
(Okay sorry, I have to correct myself here, it’s actually an editor preference and not a project settings, so I guess my whole rant about this just doesn’t have an argument behind it anymore)
dataPath += "/Library/AddressablesConfig.dat";
I couldn’t believe my eyes. It’s like… just violating everything. Now suddenly, project data is stored in the Library folder. If this is starting to gain traction, we suddenly need to put the Library folder under source control just to ensure we don’t miss anything you could put there thats actually belonging (conceptually) into Assets or ProjectSettings. I really don’t like to believe this and instead think it’s just some mishap because of shortsightedness but nonetheless this is sets a really bad example.
(But the API part still applies…)
Now, actually, it wouldn’t be so bad if we could still change the flag programatically because it only matters within specific build environments. I guess you guys already now a lot of us (especially working on larger projects) have some sort of CI setup. So I thought as a work around whilst waiting for the settings issue to be sorted out I could just change the flag before we build our bundles but…
class ProjectConfigData {...}
It’s private. Yeah I know I can now go in and do a asmref hack to get access to the flag from within our own assemblies (like we have to do for the shadergraph package) but that just can’t be the way. Seriously, if there is a user-facing setting that can be changed why is the API path blocked off? The package isn’t verified, it’s not stable, etc. so we know our risk of changing API but that’s easier to deal with than trying to get all these workarounds into place just to tear them off later on.
This made me really furious because it’s just a pattern that seems to repeat itself over and over again.
So tl;dr
- Project settings belong to ProjectSettings/*
- User facing settings in the GUI should be accessible via API as well
