Spent some time this week experimenting with making my own packages as git repos hosted on gitlab. Overall it is promising but there were a few pain areas that I just wanted to report my feedback on.
Project Structure:
currently your package folder has to be the root of your repository which makes it kind of awkward to develop. Ideally you will be developing your package inside of a Unity project so assuming you want that project to be in git as well the only solution is workarounds involving sub modules or sub trees. It works fine but I feel like there could be a more convenient solution
Versioning Support:
currently there is no official support for package versions or updating your packages. This is a pretty important feature. You can work around it by manually editing the json but I think this needs to be supported in the package manager ui
Dependencies:
this is by far the most glaring deficiency. there really needs to be a way to make git hosted packages dependent upon other git hosted packages.
I really like the idea of the package system and think this could be the future of unity assets, particularly open source ones distributed outside of the asset store so I hope you continue to work on custom package support.
Totally agree on those points (particularly hooking a package to a Git subdir would be excellent for a lot of reasons)
Recursive as it might sound… maybe if those things get to a testable stage it would be possible to release a packaged version with updates to the package manager without having to jump Unity versions…?
Thank you for the great feedback! We take this all onboard and are currently working on the issues you raised. Can’t go into much more detail than that for now, sorry!
I am wondering if you had any updates of those questions and also, if not, where would it be the right place to check that some of those questions have been addressed? Is there a good way to track down package-manager-related development?
I am thinking, specially, on the “project structure” part of the conversion, being able to hook to a subdir of a repo (rather than the root) would be extremely helpful for us. I can see how a lone dev might not have that much of an issue, but when several people develop a single package and they need a reference project for testing and the like it does get complicated (and there are no good solutions for that: two repos? messy, single repo + split? breaks down, soft links? need to be replicated by hand (particularly tricky in multiple dev platform setups) etc, etc)
So, assuming that one feature is still on the way, how could I check that it’s made it without bugging you guys? ;D
The documentation is in the work. Here is the draft that I sent to the technical writer:
Path query parameter (Subfolder)
You can specify a repository subfolder for a Git package through the path query parameter. The Package manager will only register the package located in the specified repository subfolder and disregard the rest of the repository.
This feature was introduced in Unity 2020.1.a21
Special considerations:
path must be a relative path to the root of the repository. An absolute path won’t work. (ex: path=c:\my\repo\subfolder is , path=/subfolder is )
… and . indirection notation is supported but will block at the repository root (i.e. /…/…/… will resolve to / )
path query parameter must be placed before the revision anchor. The reverse order will fail.
A package manifest (package.json) is expected in the specified path.
Does that allow us to have dependencies of other subfolder as package dependencies ?
Like in the package.json of https://github.com/user/repo.git?path=/packageA
can I have https://github.com/user/repo.git?path=/packageB
And more importantly, is the “multiple version” (like all the unity package, having the versions available and being able to hit “update” if there is a newer version according to SemVer) support coming ? Is there an ETA on that ?
Ok cool, because currently I have to manually add packages in order, or I get errors, which is pretty bad for users.
Really ? Isn’t it already implemented ? Because it’s how it works with all unity packages, and it would be really cool to have for us aswell
Maybe not the “select your version from all available”, but at least being able to upgrade with a button on the package manager. Having to delete the lock and all that is extremely not user-friendly, and a normal thing to have for managing packages
Oh, yes! That we definitely want to support. My answer was about implementing a Git client in the Package Manager UI to enable listing branches, tags, and parse package versions, etc… This we don’t have plans to do.
On the input field “Add from git URL…”, I cannot type “#” (but I can paste it).
I made a github action file that will split a repo containing multiple packages to branches, that you can get with https://github.com/YourUserName/MainRepoName.git#PackageName and will also rename “Samples” to “Samples~” and “Documentation” to “Documentation~” so you work on your project with everything, but it’s fine in the git packages
Your main repo need to be structured like this :
MainRepo
- Package1
- Package2
- ...
Here is the github action :
name: Create package branches
on:
push:
branches:
- master
jobs:
rename_samples:
name: Create branches
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: |
for i in `ls -d */`; do
git checkout master
branch=${i::-1}
if [ `git branch --list $branch` ]; then
git branch -d $branch
fi;
git subtree split -P $branch -b $branch
git checkout $branch
git config --global user.name 'github-bot'
git config --global user.email 'github-bot@users.noreply.github.com'
if [[ -d "Samples" ]]; then
git mv Samples Samples~
rm -f Samples.meta
git commit -am "rename: Samples => Samples~"
git push -f -u origin $branch
else
echo "${i}Samples does not exist"
fi
if [[ -d "Documentation" ]]; then
git mv Documentation Documentation~
rm -f Documentation.meta
git commit -am "rename: Documentation => Documentation~"
git push -f -u origin $branch
else
echo "${i}Documentation does not exist"
fi
done;
It’s probably not perfect, but it’s fine for what I wanted ! (and way easier to work with than working in the Packages/ folder of unity
First, that’s fantastic!
Second… is there a way to get that through updating the package manager itself? I could use this yesterday but won’t be able to migrate our Unity to 2020 in, well, quite a while. It would be incredibly useful if stuff like this could be cherry picked!