Search Unity

  1. Unity 2019.1 beta is now available.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. We're looking for insight from anyone who has experience with game testing to help us better Unity. Take our survey here. If chosen to participate you'll be entered into a sweepstake to win an Amazon gift card.
    Dismiss Notice
  4. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  5. Unity 2018.3 is now released.
    Dismiss Notice
  6. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

Package dependent compilation

Discussion in 'Package Manager' started by Hubertsn, Jul 23, 2018.

  1. Hubertsn

    Hubertsn

    Joined:
    Aug 7, 2015
    Posts:
    6
    With the new package manager it would be great to have symbols for every package or at least for the built-in packages, so you can use #define directives for code depending on a package like you can use them already for platforms and unity versions.

    In other threads I read that some packages like the ECS use the Player Settings/Sciprting Define Symbols, but I couldn't find an overview which packages would already define a symbol.
     
  2. okcompute_unity

    okcompute_unity

    Unity Technologies

    Joined:
    Jan 16, 2017
    Posts:
    345
    Hi @Hubertsn ,

    This is something we are evaluating at the moment. Would having only one symbol for detecting the package presence would be valuable for you? The challenge we are facing in replicating Unity versions symbols scheme is the proliferation of symbols. Let say you have 100 packages in your project, defining symbol for each package versions and any helpful variations (ex: MY_PACKAGE_VERSION_2_2_3, MY_PACKAGE_VERSION_1_OR_GREATER, MY_PACKAGE_VERSION_2_OR_GREATER, MY_PACKAGE_2_2_OR_GREATER, etc) could degenerate quickly. If you could expand on your use case it would be really helpful to define the best solution.

    As for the ECS specific symbol, I suggest asking the question in the ECS forum.

    Regards,

    Pascal
     
  3. Hubertsn

    Hubertsn

    Joined:
    Aug 7, 2015
    Posts:
    6
    Hi @okcompute_unity / Pascal,

    Detecting the package presence would be a good start and in my case sufficient. Sure there will be problems with version compatibility, but I can see that this can get wild with the possibilities of packages.

    My first case where I would need it is the following. I'm using PlayMaker and made a Git Submodule out of it so I have to maintain it just once. PlayMaker offers a wide range of Scripts/Actions for Physics2D. But not all projects use Physics2D and so an error is thrown which could be fixed using a symbol for Physics2D to check if the package is present in the current project.
    For now I moved the Physics2D Actions to an optional unitypackage.

    Greetings
    Michi
     
  4. okcompute_unity

    okcompute_unity

    Unity Technologies

    Joined:
    Jan 16, 2017
    Posts:
    345
    Ok. Will see if it make sense to start up with just this one symbol. Having one voice voting for the feature helps :)

    Thanks for you feedback!

    Pascal
     
  5. sindrijo

    sindrijo

    Joined:
    Mar 11, 2014
    Posts:
    9
    This would allow packages to have 'optional dependencies' on other packages, which I'm not sure is such a good idea.
    It is better to separate 'extra features that have a dependency' into another package (which is dependent on your 'main' package).

    A project is either dependent on a package or not.

    MyPackage (Not dependent on 3rd-party package)
    MyPackage-ExtraFeatures (Dependent on 3rd-party package)

    In any case if this were to be added the defines should probably use a prefix so that they can more easily be searched for, like maybe 'PACKAGE_ or just 'PKG_'
     
  6. Hubertsn

    Hubertsn

    Joined:
    Aug 7, 2015
    Posts:
    6
    @sindrijo Your solution is good as well. It might result in duplicate code. Both solutions have their ups and downs.

    I have another issue on the subject which needs either of the solutions. You can't use the Cinemachine package without the Physics2D package because CinemachineConfiner.cs depends on Physics2D. But to use Physics2D is optional for the script (as far as I understand it).

    EDIT: The Cinemachine and Physics2D package problem is discussed here.
     
    Last edited: Aug 10, 2018
  7. steego

    steego

    Joined:
    Jul 15, 2010
    Posts:
    865
    @okcompute_unity has there been any traction on this? I see there is a "optionalDependencies" field allowed in package.json, is this used for anything?

    Maybe a solution to not having to have symbols for every package is to just have them for the packages that are listed in optional dependencies, and then only within the package that belongs to that package.json?
     
  8. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    60
    @steego The "optionalDependencies" field that is often seen in package.json files is supported by npm only. The Unity Package Manager implements a different dependency resolution algorithm and does not use that field.

    Support for optional compiler symbols defined is being added in the 2019 releases. It works similar to what you suggested, except for two key differences:
    - they are defined in asmdef assets (see https://docs.unity3d.com/2019.1/Documentation/Manual/ScriptCompilationAssemblyDefinitionFiles.html - note that the documentation has not been updated yet to include this new feature)
    - they are not auto-generated by convention, but defined manually.

    As a result, only symbols you define based on dependencies you choose will be added during compilation of your assemblies. While this might seem an odd choice, this gives you a lot more control over your asmdef defines. You can even define different symbols for different versions of the same dependency, whether optional or not while avoiding symbol "pollution". It also does not require you to use VERY_LONG_SYMBOLS_THAT_KEEP_ON_GOING_FOREVER_VERSION_1_0_OR_NEWER in your code, and it does not require any action on the part of the author of the package you're using. You may even use those defines to detect whether a module is enabled (e.g. Physics, ...) or not.
     
    Hubertsn and steego like this.
  9. steego

    steego

    Joined:
    Jul 15, 2010
    Posts:
    865
    Ok thanks, that sounds promising :)