Search Unity

Internal API. Important!

Discussion in 'Addressables' started by androshchuk-vladyslav, May 5, 2020.

  1. androshchuk-vladyslav

    androshchuk-vladyslav

    Joined:
    Dec 13, 2015
    Posts:
    127
    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!
     
  2. joe_nk

    joe_nk

    Joined:
    Jan 6, 2017
    Posts:
    67
    +1 for this, to create custom build scripts, I'm basically having to copy/paste a lot of internal code
     
    androshchuk-vladyslav likes this.
  3. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    973
    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.
     
    phobos2077 and AlexandreDelan like this.
  4. androshchuk-vladyslav

    androshchuk-vladyslav

    Joined:
    Dec 13, 2015
    Posts:
    127
    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.
     
  5. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    973
    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.
     
    phobos2077 likes this.
  6. Jribs

    Jribs

    Joined:
    Jun 10, 2014
    Posts:
    154
    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.
     
    phobos2077 likes this.
  7. AlexandreDelan

    AlexandreDelan

    Joined:
    Oct 4, 2016
    Posts:
    16
    @Jribs you need to update the "Scriptable Build Pipeline" package to 1.8.2
     
  8. phobos2077

    phobos2077

    Joined:
    Feb 10, 2018
    Posts:
    350
    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.