Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify multiple upstreams #49

Closed
ComradeVanti opened this issue Sep 8, 2023 · 2 comments
Closed

Specify multiple upstreams #49

ComradeVanti opened this issue Sep 8, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@ComradeVanti
Copy link
Collaborator

Hey there. I've looked the documentation up and wanted to ask if the following is possible:

I want to install Package A from a private GitLab registry. I have setup the authentication, all is well. I specify the registry using the --registry option. The package is found.

Package A has a few dependencies. First Package B. This package is a official Unity package and so is found in the upstream. No problem. But Package A also depends on Package C which lives on OpenUpm. This fails because, to my understanding, if you specify a registry option, the given registry will replace the OpenUPM registry. Is this correct?

Would it instead be possible to prepend the registry given by --registry to the list of registries to search? So first search the custom registry, then OpenUPM and finally Unity.

I have a related question about if it would then be possible to store this custom registry in a config file somewhere so I don't have to add it every time.

I am open to attempting to introduce this change myself, I just wanted to ask first if this is already possible and I just missed it. Thanks :)

@favoyang
Copy link
Member

favoyang commented Sep 8, 2023

Your intuition is correct. The cli add searches the current registry (by default is openupm), then fallback to the upstream which is always the unity official registry. If you replace the current registry with another registry, it won't search the openupm registry anymore.

Ideally, the additional dependencies information could be stored in package.json to address the issue. So-called self-located/described package dependencies. But it weakens Unity's control on the scope registry - which everything involved a scope registry is preferred to be manually setup in the Editor by a developer instead of a script.

In reality, adding more than one registry can be a pragmatic solution - though the search ordering may introduce inconsistency when you have packages sharing the same name on more than one registry (a rare case in which I would ignore it until somebody raises the issue).

To keep the project simple, no configuration file is supported at the moment. Adding support for environment variables could be a workaround like OPENUPM_REGISTRY=....

@ComradeVanti
Copy link
Collaborator Author

Thanks for the response. I understand the issue. Ultimately self-describing packages would be neat, but I guess we will have to wait and see for that.

When it comes to specifying multiple upstreams, could we make it so the --registry option can take an arbitrary number of arguments ie. registries, which will be searched in the specified order?

So in my case it might be openupm add my.package --registry https://myprivateregistry.com https://package.openupm.com. It can also still use Unity as a fallback. For compatibility we could also introduce a new --registries option instead.

@favoyang favoyang added the enhancement New feature or request label Jan 17, 2024
ComradeVanti added a commit that referenced this issue Apr 26, 2024
Currently the resolved dependencies have a flag indicating whether they are resolved from the primary or upstream registry.

To prepare for the case where the app might use n registries (#49) refactor to instead specify the package source.
ComradeVanti added a commit that referenced this issue Apr 26, 2024
Currently the resolved dependencies have a flag indicating whether they are resolved from the primary or upstream registry.

To prepare for the case where the app might use n registries (#49) refactor to instead specify the package source.
ComradeVanti added a commit that referenced this issue May 18, 2024
This PR adds a service for resolving packuments by searching a list of source registries in order. For now this is only used in cmd-view (which has the nice effect of making the cmd function cli-logic only), but it could also be used in other places in the future, especially when it comes to #49.
@openupm openupm locked and limited conversation to collaborators May 29, 2024
@ComradeVanti ComradeVanti converted this issue into discussion #349 May 29, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants