Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Join us on Dec 8, 2022, between 7 am & 7 pm EST, in the DOTS Dev Blitz Day 2022 - Q&A forum, Discord, and Unity3D Subreddit to learn more about DOTS directly from the Unity Developers.
    Dismiss Notice
  3. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

Question Is there a way to "try" to add a package, if scopedRegistry exists?

Discussion in 'Package Manager' started by MrLucid72, Aug 2, 2022.

  1. MrLucid72

    MrLucid72

    Joined:
    Jan 12, 2016
    Posts:
    887
    For example: We want to add backwards compatibility for 2019 in a plugin.

    This requires a bunch of dlls like System.Buffers. We want to use a scopedRegistry to get them. If it's not in their manifest file, then we get a giant error "COULD NOT IMPORT DEPENDENCIES!!".

    However, since this is ONLY for backwards compat (eg: optional), it'd be cool if I can just "try" and add it if the scopedRegistry exists in the manifest, for the purpose of less friction to the end-user. If they're using 2020+, then the dependencies aren't even required.

    Or.... is there a way, in the package.json, to indicate you only need these dependencies if Unity <=2019?

    TL;DR:
    Is there some sort of "try to add this optional dependency, if this scopedRegistry exists?" Or some sort of conditional "if Unity <=2019, require these dependencies"? For less end-user friction.
     
  2. CodeSmile

    CodeSmile

    Joined:
    Apr 10, 2014
    Posts:
    1,612
    System.Buffers is a .NET DLL, right? Technically, you can't add those to your own asset because you're not entitled to redistribute them, so it's possible Asset Store review might flag the asset for this.

    If I had to do this, I would first consider how many users I using 2019 own and use my asset, or might be inclined to purchase it with the intention of using it with Unity 2019. If this is not a serious amount, I would just set the compatibility level to 2020 but make it import without issues in 2019 though with a message popup that explains what the user needs to do to restore functionality (ie copy System.Buffers from xxx to Assets/).

    It's been three years past 2019, I think those users expect an increasing level of friction. ;)

    PS: I don't know of a way to specify different dependencies based on Unity version. You could make a second product/release specifically aimed at Unity 2019 (incompatible with 2020+). That would also enable you to see how much sales you make with each version.