Search Unity

  1. All Pro and Enterprise subscribers: find helpful & inspiring creative, tech, and business know-how in the new Unity Success Hub. Sign in to stay up to date.
    Dismiss Notice
  2. Dismiss Notice

Custom Package with Git Dependencies

Discussion in 'Package Manager' started by OloinMilsom, Feb 12, 2019.

  1. OloinMilsom

    OloinMilsom

    Joined:
    Jan 21, 2019
    Posts:
    2
    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?
     
    Last edited: Feb 12, 2019
  2. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    259
    For security and stability reasons, this is currently not supported, by design. I can't say whether or not this feature will be supported in the future for custom packages, but I expect that no published package hosted by Unity will ever be allowed this since it essentially side-steps any kind of validation/verification of the package.

    What you can do, however, is use a scoped registry (a.k.a. private registry) to publish your custom packages on a registry you control. (See https://forum.unity.com/threads/setup-for-scoped-registries-private-registries.573934/ for more information on how to set this up.)

    Also note that while the packages are embedded in your project or declared as a dependency in your project manifest, they override any package of the same name found as a package dependency during dependency resolution. So, barring the use of a scoped registry, your above setup would work if you explicitly added the Dependency package in your project manifest using a Git URL, and updated your Depender package.json so it did not declare a dependency on the Dependency package or declared it with a version (that would be ignored in favor of the project dependency on Dependency).
     
    OloinMilsom likes this.
  3. Karnsteiner

    Karnsteiner

    Joined:
    Mar 24, 2013
    Posts:
    25
    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. }
     
    k0dep and Stephen-Hodgson like this.
  4. k0dep

    k0dep

    Joined:
    Jul 21, 2013
    Posts:
    5
  5. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    549
    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
     
  6. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    259
    Hi @Thaina,

    I'm sorry to hear that the Package Manager does not exactly fit your requirements.

    We are still working on putting the required infrastructure, tooling, and publishing flows to enable external contributions to the Package Manager registry. That is why I mentioned setting up a private registry would be the first step in sharing custom packages.

    Setting up your own registry (for instance Verdaccio -
    https://github.com/verdaccio/verdaccio) is actually pretty simple. It's installed using npm, and run using a single command-line. Configuring the Package Manager to use that scoped registry is also not too complicated - an action you need to do once per project so the Package Manager knows where to look in addition to the main registry (see https://docs.unity3d.com/Manual/upm-scoped.html) when it resolves the project's dependencies.

    For example, you could add the following to a project manifest:
    Code (CSharp):
    1. "scopedRegistries": [
    2.     {
    3.       "name": "My Registy",
    4.       "url": "<http(s)-url-to-your-registry>",
    5.       "scopes": [
    6.         "com.thaina"
    7.       ]
    8.     }
    9. ],
    10.  
    and all packages whose name begins with
    com.thaina.
    would be fetched from that registry, which you're free to administer as you wish.
     
  7. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    549
    @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
     
    Last edited: May 6, 2019
  8. insominx

    insominx

    Joined:
    Jan 23, 2012
    Posts:
    30
    This seems to be limited to Github due to Topic. Is there a way to make this work elsewhere like off of gitlab?
     
    k0dep likes this.
  9. k0dep

    k0dep

    Joined:
    Jul 21, 2013
    Posts:
    5
    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.
     
  10. Rock360

    Rock360

    Joined:
    Oct 26, 2016
    Posts:
    8
    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.
     
  11. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    549
  12. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    259
    Hi @Thaina,

    Git-based dependencies in packages are on the roadmap for 2020. I don't have a specific ETA however.
     
  13. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    549
    Thank you. But still, could it be possible for opensourcing it, so we could contribute or just using it as is?
     
  14. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    259
    I'm not sure what the plans regarding open sourcing it. At this time it's not possible but I will pass the suggestion along. Thank you for your continued interest!
     
    Thaina likes this.
  15. nilsdr

    nilsdr

    Joined:
    Oct 24, 2017
    Posts:
    348
    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?
     
  16. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    549
    Unity 2020 is already beta. Where is git dependency support?
     
  17. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    645
    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.
     
  18. Davidtr_Unity

    Davidtr_Unity

    Unity Technologies

    Joined:
    Mar 5, 2020
    Posts:
    34
    Hi @nilsdr,

    Yes, this is supported. You would need to configure both scoped registries at the project level.



    Hi @Thaina,

    Git dependency support didn't make 2020.1 but it is still on the roadmap.
     
    Thaina likes this.
  19. Jerry-Lee

    Jerry-Lee

    Joined:
    Apr 10, 2014
    Posts:
    2
    Last edited: May 28, 2020
    EloiExperiments likes this.
  20. Saucyminator

    Saucyminator

    Joined:
    Nov 23, 2015
    Posts:
    45
    This issue I was having took a while to find. Please add this info in the Known issues thread.
     
  21. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    374
    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?
     
  22. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    549
    Now is 2020.2 alpha. Why it still not support?
     
  23. UnityMaru

    UnityMaru

    Community Engagement Manager Unity Technologies

    Joined:
    Mar 16, 2016
    Posts:
    1,082
    Hey there. This is something that is still on our radar but we haven't got any form of ETA to provide as to when this will be supported.
     
  24. aut0mata

    aut0mata

    Joined:
    Aug 22, 2014
    Posts:
    4
    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?
     
    The_Swiss_Guy likes this.
  25. UnityMaru

    UnityMaru

    Community Engagement Manager Unity Technologies

    Joined:
    Mar 16, 2016
    Posts:
    1,082
    It sounds like you're having issues with using private credentials to access a secure repo. It might be worth referring to the troubleshooting page for ssh and https when using git Urls. https://docs.unity3d.com/Manual/upm-errors.html#ssh-add
     
  26. Shaunyowns

    Shaunyowns

    Unity Technologies

    Joined:
    Nov 4, 2019
    Posts:
    328
    Got a bit more of an update from the PackMan team:

    "Unfortunately this is probably a ways off in terms of priorities. We are currently working on high priority items so new features like this have taken a back seat. Also, you may have heard the announcement that future versions of Unity will have dedicated themes and unless your work pertains to one of these themes, it will be harder to get new changes into the editor. For the foreseeable future, we may be working on bug fixes and stability, sorry!"
     
  27. sandolkakos

    sandolkakos

    Joined:
    Jun 3, 2009
    Posts:
    198
  28. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    549
    Nearly the end of 2020. Do we have any progress about this?
     
  29. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,730
    Git-based dependencies in packages would skyrocket the usefulness of Package Manager for me (link). Would love to see this in 2019.4 too.
     
    Jes28 and ImpossibleRobert like this.
  30. Sarkahn

    Sarkahn

    Joined:
    Jan 9, 2013
    Posts:
    438
    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.
     
  31. sandolkakos

    sandolkakos

    Joined:
    Jun 3, 2009
    Posts:
    198
    @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.

     
  32. archer-scott

    archer-scott

    Joined:
    Nov 19, 2020
    Posts:
    1
    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?
     
    ImpossibleRobert likes this.
  33. UnityMaru

    UnityMaru

    Community Engagement Manager Unity Technologies

    Joined:
    Mar 16, 2016
    Posts:
    1,082
    Hello there,

    Just to update things. The feature is still something that the team know is hotly requested and there's still no immediate plans to work on this, but it's certainly something that's not going to be forgotten about.
     
  34. Bodix_

    Bodix_

    Joined:
    May 6, 2018
    Posts:
    15
    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!
     
  35. UnityMaru

    UnityMaru

    Community Engagement Manager Unity Technologies

    Joined:
    Mar 16, 2016
    Posts:
    1,082
    With the amount of internal changes going on and the vast scope of the Package Manager, the team do not provide a fixed roadmap on what the current priorities are to the public. We'd hate to one moment say that X is a priority and then Y steams along to take that promise away. Without doubt, what you've asked for is something the team do want to explore :)
     
  36. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    259
    Hi @Bodix_ ,

    Regarding question 2. (and assuming it's asking about the new package format, not Asset Store packages), the Package Manager will take into account both dependency declarations and try to find a version of that package which works for both dependents. For instance, if an existing package in a project depends on "super-package" at version 1.0.0 and the user adds your package which needs version 1.2.0, then "super-package" will be updated to 1.2.0. If the situation was reversed (i.e. your package needed version 1.0.0 while 1.2.0 is in the project), then "super-package" would remain at 1.2.0.

    That said, dependencies declared in the project manifest using "file:<path>" expressions or Git URLs will override this computation, so if the project directly depends on "super-package" through a Git URL, then the Package Manager chooses to keep the Git-based package. If that revision of "super-package" doesn't work for your package, then there will probably be errors in your package, and it's up to the user to choose a different Git revision, or perhaps fall back on a published version of the package, or maybe even embed your package to make it work with that Git-based package.
     
  37. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    374
    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?
     
  38. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    259
    Dependency resolution is a two-step process: first, figure out what packages should be present in the project; second, install any missing package.

    Due to the fact that Unity cannot currently load different versions of the same asset, different versions of the same package cannot be used at the same time. So in step 1) above, the Package Manager uses package versions (which follow the Semantic Versioning specification) to determine which set of packages to use. In addition, step 1) above accepts Git URLs and file paths. The problem in Step 1 comes from dealing with conflicts - the Package Manager has no way to know which of a local package referenced by file path or a remote registry-based package referenced by version should be used, as it has no way of knowing which one (or even if any) will be compatible for both dependencies. To avoid this issue, only a project manifest can include non-version dependencies, and those are assumed to override (i.e. be valid in lieu of) indirect version-based dependencies.

    We're aware that this is a strong limitation for various advanced use case, and we plan on improving this, but as @UnityMaru said, we have no ETA at the moment.
     
  39. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    374
    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?
     
  40. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    259
    Hi @ImpossibleRobert,

    That's most definitely not a stupid question.

    The problem is that while the version of a package is used to uniquely identify packages on the registry, this isn't the case for packages looked up elsewhere. For instance, there may be thousands of revisions on a Git repository which all have the same "version" but potentially contain wildly different contents and APIs. For this reason, assuming that the "version" in a package.json from given Git revision uniquely identifies is incorrect. Even if the Semantic Versioning compatibility rules have been strictly followed, different branches could have the same incremented version but different contents/API changes. It just cannot be reliably and safely assumed that the "version" in a Git-based package will fully respect the SemVer specification in terms of compatibility or even identity. And this is equally true with arbitrary local package paths. Therefore, packages from arbitrary sources are treated as non-comparable for the purpose of conflict management and dependency fulfillment - that is, two Git revisions with the same version may be different packages, and even differ from the officially published version of the package in a registry. In a system where different package versions can co-exist, conflicts in this case could be trivially solved by choosing both packages, but Unity doesn't support this.

    I hope this answers your question!
     
    ImpossibleRobert likes this.
  41. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    374
    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?
     
  42. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    259
    True, but you could have two different Git URLs pointing to specific commits whose package.json has the same version, but the contents of the Git revision differ (different assets/code). So this means the package manager needs to treat every single commit as its own version, regardless of what the SemVer version is. It's just not possible to reason about compatibility with arbitrary Git revisions.

    Barring the guarantees enabled by some sort of registry of curated versions, guaranteed to be unique and immutable, and whose "versions" are comparable (by SemVer), there's only two solutions when dealing with conflicting dependencies: use both (assuming the underlying system is able to handle this, such as Node.js's module loading system), or defer the full responsibility to the user (e.g. to pick one of the conflicting packages and deal with incompatibilities, or choose different dependency versions, or different dependencies, or create their own Git fork to merge and fix the incompatibilities in the conflicting package itself, etc.)

    Unity cannot load two versions of the same package side-by-side. This would require having a way to disambiguate duplicate asset GUIDs when resolving asset references, duplicate assemblies when resolving assembly references at compile time and runtime, etc. not to mention the potential impact on built Player size. None of this is impossible in theory, but in practice this just isn't how it works.
     
  43. DaleEidd

    DaleEidd

    Joined:
    Aug 11, 2019
    Posts:
    23
    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.
     
  44. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    374
    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.
     
  45. DaleEidd

    DaleEidd

    Joined:
    Aug 11, 2019
    Posts:
    23
    A git tag points to a specific commit.
     
    The_Swiss_Guy and Hurri04 like this.
  46. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    374
    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?
     
  47. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    259
    Hi @DaleEidd and @ImpossibleRobert ,

    Convention-based tags may seem like a fine idea, but they won't work for everyone and every case. Quite a few repository (including here at Unity) host multiple packages in the same repo and don't necessarily publish all packages in step-lock. This would be pretty bad, since a package might have no change and yet have a newer "minor" version, or another might have a breaking change, forcing every other "version-step-locked" packages to also claim to have a breaking change by bumping their major version. And lastly, tags are just one way to use Git URLs, and as you noted yourself, they are immutable by convention only.

    Moreover, Git does not have an API to fetch tags and specific files without fetching the whole revision. Yes, some server backends have Web APIs to access this information, but then there's the problem of authentication and vendor-specific Web APIs (I'm pretty sure Github, Bitbucket and Azure DevOps all have different APIs to implement similar APIs.) So currently we rely on the Git CLI itself to provide this common API surface, without relying on experimental features that may not be stable or that users might not even have in the Git version they use.

    So all in all, why it may sound like a good idea on the surface, it's not that simple. But we've got some ideas already, and what you suggested may be part of the final solution yet! :)
     
    Last edited: Mar 29, 2021
  48. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    549
    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
     
  49. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    549
    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
     
  50. Hurri04

    Hurri04

    Joined:
    Nov 27, 2017
    Posts:
    46

    Hoo boy, phrasing...?
     
unityunity