UPM versions of UniRecast and DotRecast

[Danil0v3s]

Hey, been lurking around and trying to get things working for a while and been wondering if we should make both UniRecast and DotRecast a UPM package.

For that matter, I've prepared a fork of each repo and created a new branch with the UPM structure. You can view them at

• UniRecast
• DotRecast

One can add both dependencies to their project using the Unity Package Manager with the following pattern: [repo url].git#unity and it will target the unity branch with the correct structure. I've taken the time to make sure the Assembly Definitions are created and point to the correct places.

For development purposes, you can create a folder with the package name inside the ProjectFolder/Packages dir, for instance, com.defnotagamestudio.unirecast and develop normally. Unity will detect that folder as a local lib.

What do you think?

[ikpil]

Hello, @Danil0v3s

Firstly, I agree with the suggestion of UPM projectization. Offering the project as a package can significantly enhance user accessibility.

However, I'd like to seek clarification on the rationale behind separating DotRecast and UniRecast into individual UPMs. I have a few inquiries in this regard.

Could you provide insights into the considerations behind splitting DotRecast and UniRecast? I'm curious if this decision is based on factors such as modularization, dependency management, maintenance, updates, or user convenience. It would be great if you could share your insights on this matter.

A more detailed explanation of this decision would be beneficial for our discussion. Thank you.

[Danil0v3s]

I'm glad you liked!

The reason I chose to split these two is because they're indeed two different projects and DotRecast is a dependency of UniRecast.

I couldn't add DotRecast directly as a dependency of UniRecast because I don't have it published in any package registry, I'm also not sure whether Unity supports other registries other than their own.

The way I see it is UniRecast is a tool built on top of DotRecast and their lifecycle is different, therefore they should live in different repositories. Updating each package should be easy enough once they're on the UPM and as long as we publish the versions correctly to the package.json file

[ikpil]

Thank you for your advice.

I am currently exploring various aspects of Unity Package Manager (UPM). When it comes to managing with Git, I'm considering:

https://repo.git or https://repo.git#unity or https://repo.git?path=src/.... or .unitypackage

Which approach is more developer-friendly? Which approach is more deployment-friendly? Which approach has fewer dependencies?

I am currently referencing the UniTask project. If you have any recommended projects or advice related to this, please let me know.

[Danil0v3s]

My personal opinion regarding the URLs would be the middle one repo.git#unity, and the reason for that is because we can leverage GitHub Actions to move files around whenever there's a commit on the main branch and prepare the unity branch, bumping the version and whatever else we need (release notes, etc).

• Developer friendly, would be adding the package locally inside the Packages folder which then we can develop normally since Unity will generate a .csproj for the project inside the Packages folder.
• Deployment friendly, IMO will always be the UPM with a git url, since updating is super easy
• Fewer dependencies would be if we could publish to a package registry, which would allow us to reference the packages directly by their name on the main project package.json, just like any other Unity's dependency.

Since you're referencing UniTask, that one would also need to be on a registry if we wanted to keep our projects in a registry. But since they're not currently in a registry, if you reference their .asmdef in UniRecast, when someone install the UniRecast dependency, they will also need to install the UniTask and then the project will compile because the .asmdef GUID won't have changed

[ikpil]

Summing up, the most favorable scenario appears to be offering it in the repo.git format. Additionally, DotRecast will be integrated into UniRecast rather than being provided separately through UPM.

The reasons for this decision are as follows:

1. UniRecast aims to implement DotRecast's Demo Tool.
2. To minimize inconvenience for users until an official UPM is available.

If you have any concerns, please feel free to let me know. I will review and consider them.

[ikpil]

Could you submit a pull request for the UniRecast UPM that has been worked on?

[ikpil]

@Danil0v3s I've completed the merge. There's still some polishing and organizing to do, but it looks good for testing.