Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Local package grouping other local packages

Discussion in 'Package Manager' started by pal_trefall, Oct 3, 2019.

  1. pal_trefall

    pal_trefall

    Joined:
    Feb 5, 2019
    Posts:
    78
    Hi,

    I'm experimenting with a project setup where I write Feature Modules in isolation. It's an architectural benefit in that it isolates features, promotes testable code, and promotes simpler feature re-use between projects. This is easy to support in the manifest, as I can add a file path to the local module dependency.

    Working with the new Netcode and Testing suite, however, for each feature I have four modules (client, mixed, server, tests), and this makes the manfiest rather messy. It would be very nice to be able to set up a hierarchy of modules, so that for each feature I could have a root package that had dependencies to the four packages of that feature. But I noticed that dependencies in packages only support the semantic versioning dependencies, and not file or url paths.

    Is there any way I can go about adding this kind of hierarchical dependencies in my local packages? Do I have to use scoped registries? For this type of problem it feels a bit overkill?

    Thank you.
     
  2. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    545
    Hi @pal_trefall,

    Supporting non-Semver dependencies in packages is on our roadmap but we have no ETA yet.

    Scoped registries is probably the best way to replicate the same functionality. You're saying it sounds overkill, but it's not that hard to set up a Verdaccio server, for instance. YMMV, depending on the number of people who will be using it, their location (local network or internet), their relationship to your company (access over VPN or requires authentication - something we don't support in scoped registries yet), etc.

    Other options might include Git repositories with submodules (since we also don't support Git-based packages referencing other packages using Git URLs at the moment).

    I don't think you should mind the project manifest.json file becoming "messy" just because it's listing dozens of dependencies that you're actually using (any more than e.g. you should care about meta files becoming messy) - and in that sense, creating meta packages that only serve to group other packages to facilitate a bunch of related packages seems to go against that purpose. In fact, grouping your packages such make it convenient to add everything at once, but that's also a downside, since you might not want _everything_. If you _do_ need everything every time, then perhaps you should consider merging them into a single package but define separate assemblies (using .asmdef) to split features.
     
    pal_trefall likes this.
  3. pal_trefall

    pal_trefall

    Joined:
    Feb 5, 2019
    Posts:
    78
    Thank you for the fast reply!

    I didn't actually think of a single package file with multiple asmdefs, I think that approach will do just fine for now!

    Is folders for package modules (in visual studio) on the todo list? That would be very useful when looking at not just importing third-party packages, but use it for feature moduels as well.
     
  4. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    545
    I'm not sure I quite understand what you mean - do you mean grouping C# projects from the same package together under a Solution folder?
     
  5. pal_trefall

    pal_trefall

    Joined:
    Feb 5, 2019
    Posts:
    78
    In visual studio all items in a package module lists without folders for me, while in-project asmdef projects lists with folders.
     
  6. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    545
    Ah, that's because packaged code is referenced as Assembly references since any change you make to the package code would be done on a local-only, temporary copy in your project cache. Any change you make cannot be reliably shared to others on your team, to build machines, or even reliably kept around on the same machine (the package manager will promptly revert those changes). Note that editable packages, such as those directly located under
    Packages
    or referenced in your
    manifest.json
    using
    file:<path>
    should normally result in a generated C# project (.csproj) with all their code visible in VS.
     
    pal_trefall likes this.
  7. pal_trefall

    pal_trefall

    Joined:
    Feb 5, 2019
    Posts:
    78
    Mine are referenced with the file path in manifest, but I will try to do it in Packages folder to see if it might give me folders then.

    Thank you
     
  8. pal_trefall

    pal_trefall

    Joined:
    Feb 5, 2019
    Posts:
    78
    Hah, putting the module folders under Packages resolved the issue for me, and I can now work on my modules, in all their glory, with folders. Thank you!
     
    maximeb_unity likes this.