Internal API. Important!

Hi. We were standing on Addressables 1.6.2. Our system is using custom build script which overrides
BuildScriptPackedMode. However there are some steps in BuildScriptPackedMode which are necessary for us to change. And in 1.6.2 for my biggest gladness I just copied all code from BuildScriptPackedMode, changed what I needed and override my CustomBuildScriptPackedMode. It was perfect.

But in 1.8 torture returned back:

  • IBuildLogger is internal
  • m_Log is also internal
  • ContentUpdateContext is internal
  • RevertUnchangedAssetsToPreviousAssetState is internal

Also the same situation with LoadContentCatalogAsync. Now we have public API only to load catalog without hash and saving to disk throw CatalogProvider. It loads as regular json. We have 10+ catalogs, and it takes ~1sec on startup.

Why with so extendable system you make new functionality internal?

We are using Addressable is big production project and want update to new stable versions. That is very critical for us. I will be very appreciated you to remove internals from those API. I want to avoid a duplicating all code to own module. Thanks!

4 Likes

+1 for this, to create custom build scripts, I’m basically having to copy/paste a lot of internal code

1 Like

To be honest, if you are making your own stuff I’d recommend just bringing the package straight into the packages folder and change anything you need.

  • Bring the package into the packages folder
  • Rename to not have a version.
  • Commit to your repo.
  • Make whatever changes you want.

Upgrading is also really easy:

  • Update back to the revision or branch you imported the base package at.
  • Bring the new package in.
  • Commit.
  • Merge.

We’ve been customising bits and bobs of Addressables since version 0.2, this is what is nice about packages.

2 Likes

Sure. But I want to use original package. It’s isn’t too hard to keep API and extendability in Addressable public, as for me.

Just be pragmatic. You know full well that this issue is going to keep happening everywhere across Unity and you have a very easy solution for it. Just take it.

1 Like

Yes, we had to go the route of moving the package to the package folder because they weren’t fixing critical bugs fast enough so we had to do it ourselves. It has been great.

1 Like

@Jribs you need to update the “Scriptable Build Pipeline” package to 1.8.2

The same issue with WebRequestQueue. What’s the obsession with everything internal, I don’t get it?! The whole point of allowing to write custom providers is to be able to do everything that’s in base providers but differently. Now this is more complicated than it should be because of the amount of extra code you need to copy-paste into your project.