Skip to content
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

[enhancement]: Allow to install adapters which are scoped packages (Vendor-feature) #2942

Open
1 task done
foxriver76 opened this issue Oct 17, 2024 · 5 comments · May be fixed by #2943
Open
1 task done

[enhancement]: Allow to install adapters which are scoped packages (Vendor-feature) #2942

foxriver76 opened this issue Oct 17, 2024 · 5 comments · May be fixed by #2943

Comments

@foxriver76
Copy link
Collaborator

foxriver76 commented Oct 17, 2024

No existing issues.

  • There is no existing issue for my request.

Description

Currently adapters cannot be published as scoped packages because the controller cannot handle it. We could allow to also install scoped packages.

Why?

If I as a ioBroker consultant want to provide packages which are not public available to my customer, the way to go nowadays is to use a private registry, likely GitHub packages. Then some would create a scope for their customer or org and the customer should get access to all the adapters (packages) inside this scope. Hence, scoped packages are the way to go.

On the customer you would just need to put an .npmrc file in home/iobroker/ with a token with read access to the scope. Then if the customer has configured a repo containing this adapter it will show up in admin and will be installable.

Minimal Example: https://www.moritz-heusinger.de/static/repositories/fleck.json see packetName attribute.

In general this feature should never be used in the official stable and beta repository as there is no necessarity for scoped packages!

How?

We could allow e.g. a packetName attribute in the repository which represents the real package name (with scope) andon install simply alias it to the normal package name.

Downsides:

  • No possibility to install scoped packages from tarballs as aliasing does not work here
  • No GitHub install but this won't be available anyway because of private repositories in these cases
@foxriver76 foxriver76 added enhancement ⬆️ refinement 🔍 Needs refinement with core developers labels Oct 17, 2024
@foxriver76 foxriver76 linked a pull request Oct 17, 2024 that will close this issue
3 tasks
@mcm1957
Copy link
Contributor

mcm1957 commented Oct 17, 2024

This will introduce a problem with naming scope.

Currently ioBroker.myadapter package name guarantees that exactly one adapter named myadapter can exist due to naming rules on github. Inventing scoped names we will run into the situation that

ioBroker.shelly
@foxriver76/ioBroker.shelly
@mypersonal/ioBroker.shelly

might exist at npm. No idea how to handle this situation. Maybe we would need to create some registration database or something like this.

In addition all tools / checkers must be extended to handle scoped packages. (But thats not a problem only work to be planned and done)

@foxriver76
Copy link
Collaborator Author

foxriver76 commented Oct 17, 2024

It is really a vendor-specific feature, these repos cannot be checked as they are likely not be publicly available and probably are for one single user or company. Naming issues in general yes, but on repo level one will be the applied one (multi repo feature). We will refine this ticket in the next core meeting so lets see.

@mcm1957
Copy link
Contributor

mcm1957 commented Oct 17, 2024

One solution without changes could eventualkly be to use a normal adapter environment BUT to put the real code into a dependent scoped package. This way no changes to ioBroker would be required but user could not install the adapter unless they have access to the scoped package. main.js in standard could simply do nothing but log a message and / or call into the scoped and hence protected pacakge.

Eventually io-package.json could be extended to allow admin / js-controlelr to check and output a clear messages instead of crashing due to insufficiengt access righgts to dependent package.

@mcm1957
Copy link
Contributor

mcm1957 commented Oct 17, 2024

Naming issues in general yes, but on repo level one will be the applied one (multi repo feature). We will refine this ticket in the next core meeting so lets see.

As long as iob install @foxriver76/ioBroker.shelly or something like this as possible users will use it to fork variants and this will be suggested at forum for sure. We should consider this and eventually restrict in some way.

Maybe we could / should enforce that the scope name is part of the adapter name?

In general I see the usages and I understand that this is required for a commercial environement.

@foxriver76
Copy link
Collaborator Author

Scoped packages are not meant for users, no scoped package should ever be in an official beta or stable repo see initial post.

In general this feature should never be used in the official stable and beta repository as there is no necessarity for scoped packages!

This is a very specific case. In general, the feature is not a feature anyone would care about except from someone who writes an adapters which is meant for a single company. I would not allow to set packetName in the official repo which users are using!

As long as iob install @foxriver76/ioBroker.shelly

it won't be possible! See https://github.com/ioBroker/ioBroker.js-controller/pull/2943/files as a proposed implementation, it only works if the packetName is specified, as long as we do not allow this to be set in official repos all good.

@foxriver76 foxriver76 removed the refinement 🔍 Needs refinement with core developers label Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants