UPM versions of UniRecast and DotRecast about unirecast HOT 7 OPEN

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.

from unirecast.

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

from unirecast.

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.

from unirecast.

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

from unirecast.

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.

from unirecast.

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

from unirecast.

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

from unirecast.