Custom Package with Git Dependencies

Using Unity 2018.3.1f1 I am investigating if it's possible to create a dependency in a custom package's package.json to another custom package.

For example, I created two package.json files like these:

Dependency

Code (JavaScript):

1. {
2.     "name": "com.test.dependency",
3.     "displayName": "Test Dependency",
4.     "version": "0.0.1",
5.     "unity": "2018.3",
6.     "description": "bla bla bla",
7.     "category": "Unity",
8.     "dependencies": {}
9. }

Depender

Code (JavaScript):

1. {
2.     "name": "com.test.depender",
3.     "displayName": "Test Depender",
4.     "version": "0.0.1",
5.     "unity": "2018.3",
6.     "description": "bla bla bla",
7.     "category": "Unity",
8.     "dependencies": {
9.         "com.test.dependency": "https://github.com/GitUserName/Test.Dependency.git"
10.     }
11. }

I then created a new unity project and added the Depender to the manifest.json:

Code (JavaScript):

1. {
2.     "dependencies": {
3.         "com.test.depender": "https://github.com/GitUserName/Test.Depender.git",
4.         ...
5.     }
6. }

Upon opening this project I get the following error:
Package com.test.depender@https://github.com/GitUserName/Test.Depender.git has invalid dependencies:

com.test.dependency: Version 'https://github.com/GitUserName/Test.Dependency.git' is invalid. Expected a 'SemVer' compatible value.​

I'm wondering if there's anything I've missed that would get this working. If it is not possible, as the errors would suggest, to have custom dependencies in a package.json file, will this be supported in future?

 

I might be mistaken, but it seems like Oloin is referring more to a package hosted on his own git repository versus one hosted by Unity. I am also looking at this for splitting up an open source project hosted on github into several smaller packages with one core and the others as optional secondaries requiring core.

It seems implied that something like this might work based on what forum threads/documentation I've found, but now requires a user to list all dependencies of a package independently in the manifest.json file and won't account for sub-dependencies (two levels deep dependencies or more).

Package.json

Code (JavaScript):

1. {
2.     "name": "com.test.depender",
3.     "displayName": "Test Depender",
4.     "version": "0.0.1",
5.     "unity": "2018.3",
6.     "description": "bla bla bla",
7.     "category": "Unity",
8.     "dependencies": {
9.         "com.test.dependency": "1.0.0"
10.     }
11. }

Manifest.Json

Code (JavaScript):

1. {
2.     "dependencies": {
3.         "com.test.dependency": "https://github.com/GitUserName/Test.Dependency.git",
4.         "com.test.depender": "https://github.com/GitUserName/Test.Depender.git",
5.         ...
6.     }
7. }

 

Hello to all! I partially solved this problem. Here is the link to the package: github.com/k0dep/Originer

 

This is seriously annoyingly nonsense. The usable of package manager is to let us able to share any package with any dependency package and the manager will resolve all dependency automatically. If you don't let us upload all of our package on your server directly then it limit the usability of the manager. We must uselessly include all of our sub package in our own package or else we cannot share it

If we only develop individually or internally then we don't really need package manager at all. The point is to share the package as a submodule to anyone and anywhere. Scope registry is totally useless and waste of time on your side. We only need git dependency and custom dependency. I really want to ask who was think about this idea and waste all your time? Have you even think about the use case scenario before add this feature?

We just need a custom dependency. Not a useless workaround like scoped registry unless the scope registry could be resolved from dependency. If we tell people that "you can add our package into package manager" but then "oh but you also need to add this line in this file and these lines in this file and this line in these files" then it become totally pointless to have package manager

 

@maximeb_unity That's the point that I would call it pointless

The point is, this feature is Package Manager. It was named as "Package Manager" and you can see that every popular package manager, be it NPM or NuGet, has an ability to resolve all of it dependency as first priority. Because if the package can resolve dependency in one machine but failed to resolved in another machine without tweaking configuration, That package would become useless, and also the manager itself would be a totally useless manager

And to config each and every machine just to use one package is defeating the purpose of using package manager itself. So if any feature want to have be named Package Manager it should have a way to resolve dependency of any depth from the package itself without having people go manage each dependency when they just want to include another package

People try to include package in their project for their convenience. But you are making this useless package manager that force people to do inconvenience things it defeat the purpose of using Package Manager immediately

an action I need to do once per project is not acceptable for the feature named Package Manager. It must be an action I need to do once per package. It must be an action that, when I tell some people to include my package. They only really need to just include my package and done, the manager will do everything on its own to resolve every bits of dependency into that person's project, any number of person and any number of project, to have each person need to tweak each project they create just to use my package it a uselessly annoyingly inconvenience loss cost

Because the usability of the feature named Package Manager is that, I am not the one who use it. There would be many people to use it by installing my package into their project

This is why I want to ask that, have you ever think about the use case scenario of this feature? Have you ever think about the actual use case scenario of feature named Package Manager ? Who have suggest you to try doing that useless scope registry feature before custom dependency? You trying to present scope registry is telling me that you are all half heartedly in designing the feature named Package Manager. You don't understand the use case of Package Manager at all. Unless the scope registry can be resolved from the package. Which I have trying and it was not

If you making feature named Package Manager you then must have thought about this. If not you should just name it Unity Registry Package Installer UI not a Package Manager or else it will become a false advertisement

 

This seems to be limited to Github due to Topic. Is there a way to make this work elsewhere like off of gitlab?

 

Yes, indeed, the current implementation has limitations associated with GitHub. Now I am working on the development of the whole ecosystem for working with packages regardless of their location, I plan to finish by the end of the month.

 

Hi.
I found an awesome repo and thought it should be shared.
This plugin looks like a PERFECT solution for me!
https://github.com/mob-sakai/GitDependencyResolverForUnity

(From the README)

This plugin resolves git url dependencies in the package for Unity Package Manager.
You can use a git url as a package dependency!

Features

• Easy to use: just install
• Resolve git url dependencies in packages
• Uninstall unused packages that is installed by this plugin
• Support GitHub, Bitbucket, GitLab, etc.
• Support private repository
• Support Unity 2019.1+
• Support .Net 3.5 & 4.x
• Update package with a specific tag/branch

Install

• Find Packages/manifest.json in your project and edit it to look like this:

Code (JavaScript):

1. {
2.   "dependencies": {
3.     "com.coffee.git-dependency-resolver": "https://github.com/mob-sakai/GitDependencyResolverForUnity.git#1.0.0",
4.     ...
5.   }
6. }

• To update the package, change #{version} to the target version. Or, use UpmGitExtension.

 

@maximeb_unity Any updates?

If you still don't do anything then please just bring code from https://github.com/mob-sakai/GitDependencyResolverForUnity into official UPM

 

Thank you. But still, could it be possible for opensourcing it, so we could contribute or just using it as is?

 

can a custom package in scoped registry depend on another package that is in an other scoped registry? We have ar tools in our own registry which depend on the vuforia package, which is in their own scoped registry.

Can I somehow define in the package manifest that the vuforia package is to come from another scoped registry, or would I have to define vuforias registry in the importing projects manifest?

 

Unity 2020 is already beta. Where is git dependency support?

 

Unity 2020.1 is beta. Maxime only said it's on the roadmap for 2020, not if it'll land in 2020.1, 2020.2 or 2020.3 (or at all – being on the roadmap is no guarantee).

I wouldn't hold my breath waiting for it and look for alternatives in the meantime.

 

I suggest you use this: https://openupm.com/. It's better choice for you to manage dependencies in unity package.

You can check my package as a dependencies example: https://openupm.com/packages/io.github.idreamsofgame.unisharper.core/

 

This issue I was having took a while to find. Please add this info in the Known issues thread.

 

I want to add that this is really unfortunate and it seems like a very annoying design decision not to allow or actually even to prohibit this, as it works already in package manager. Why not let the users decide?

 

Now is 2020.2 alpha. Why it still not support?

 

Trying to use GitLab private repos for Packages dependencies (both SSH/HTTPS) and I`m not able to install them through UPM, not even with the cited extension...

Any ETA on fix?

 

I also created my own solution to resolve git dependencies on Custom Packages:
https://github.com/sandolkakos/unity-package-manager-utilities

I basically check if the custom "package.json" has any entries in the gitDependencies and copy them directly to the "manifest.json" of the current project.

 

Nearly the end of 2020. Do we have any progress about this?

 

Git-based dependencies in packages would skyrocket the usefulness of Package Manager for me (link). Would love to see this in 2019.4 too.

 

Just wanted to add my voice for support of having dependencies on our own git packages. After wasting far too much time trying use custom solutions to make it work I've given up on ever writing UPM packages again until this feature or some simple enough alternative exists.

 

@Sarkahn
My alternative below works very well, if you use and find anything which could be improved, please let me know and it will be a pleasure to do it.

 

Would this not be considered simply a bug of the implementation of NPM in the Unity Editor? I'm not so sure I understand the

being a reason for this not working, because to me it looks like you just aren't handling the package dependencies in a way that allows them to refer to a registry. Would this be something that can be added to a bugfix release rather than seeing this as some kind of feature?

 

Hello!
Thank you for your response!

I would be very grateful if you could answer a few of my questions:

1. I'm wondering what package manager features might be a higher priority than resolving dependencies?
2. How do I currently handle a situation where the user who downloaded my package already has another package installed that my package depends on?

Thank you!

 

Why would there be a different dependency resolution mechanism depending on where a package is loaded from? Isn't it just a matter of where to load a package from, either from local file system or from the net? And the version is always stated in the package.json, no matter where the packages reside. Doesn't Unity propagate exactly that independence with Addressables, not needing to care anymore if something is remote or local?

 

Sorry if I maybe ask stupid questions, but I still don't understand the difference. Why would a git or file reference not be a versioned dependency? It has a package version which when fed into the resolution mechanism for dependencies would be treated all the same. Why does the location of the package.json matter?

 

Understood! You would need some sort of indication that this file URL could be trusted to be immutable. You actually have such a case already: when referencing a specific commit in a git URL reference (I do that). Then you get a hardened version. But still I see your point. One would need a more holistic concept that covers more bases. In what direction are you currently thinking?

 

Not sure if you covered this or I am not understanding, but couldn't Unity just limit the scope of git dependencies in package.json files to only SemVer compliant git tags (tags aren't immutable, but changing them is a bad practice)? Then use the same version resolution strategy as normal packages? Finally, if someone needs to override with a special revision, they can use the manifest.json as before.

 

The problem is that you can have the same version in multiple commits by simply not updating the version but changing the content of the repo. The only way to ensure a reproducible git dependency is by locking to a certain commit.

 

A git tag points to a specific commit.

 

Oh I misread your suggestion @DaleEidd. Yes definitely tags could be an interesting option indeed and it would supply the needed anchor to have a version AND immutability. I like it. What do the Unity pros think about this @maximeb_unity?

 

Then how was it progressed so far

All in all currently now what I really need is to have ability to share at least specific revision for a "just worked" dependency system for sharing package, without the need to modified more than one places. Anything else could be later

 

Actually it might be easier if you allow us (we developer with unity account) to register our git repo into unity's registry database, (maybe a separated regisitry, for every third party). And enforce package's name to include our unique ID so it guaranteed no name collision

This may be hidden registry that unity would not show it, but it would be last searched target if it not found in any other registry

 

But apart from that:

Do I understand this correctly that the main problem is something like the following:

A package "A" that has been installed has a dependency to
"com.companyname.packagename": "1.0.0"

Now a package "B" is added which has a dependency to
"com.companyname.packagename": "https://github.com/CompanyName/PackageName.git"

But the package manager has no direct way of telling which is the latest version?
(And it always assumes backwards-compatibility with earlier versions?)

Now if package "B" specified
"com.companyname.packagename": "https://github.com/CompanyName/PackageName.git#1.3.0"
the package manager should be able to determine that "1.3.0" is newer than "1.0.0" and therefore pick that version automatically.

If it specified
"com.companyname.packagename": "https://github.com/CompanyName/PackageName.git#beta"
the package manager should show the user lists to manually select a version:

• show a list of versions in the Unity Registry, if there are any;
• show a list of versions in other (manually added) scoped registries, if there are any;
• and show a list of versions available in the github repo, if there are any, offering
  • versions by tag (e.g. "1.3.0")
  • versions by branch (e.g. "beta")
  • versions by commit (e.g. "123ab4c")

To fit these lists into the UI it might be good to show them under different tabs.
Each version then has an "Install" button on the side and a disabled "Installed" button for the installed version.

If the selected package version happens to not be compatible (e.g. due to API changes) this would result in compiler errors.
The user would then manually have to try out different versions until he finds one which works.
This is not ideal but worlds better than nothing.
In the best case he should then open an issue in the github repo to have this looked at by the repo owner/maintainer or directly create a pull request himself.