question: Domain Names

[simonmcnair]

Domain names are not specific to a provider, so imo, should not be manipulated per provider.

My suggestion is that the self object is changed to provide domain, domaintld, domainsld and the providers are refactored to use the appropriate new properties.
This would mean that any domain fixes are in one place. It would also mean that they were handled consistently. No provider should need more detail than TLD and SLD afaik. The refactoring should highlight that and allow for any additional properties as appropriate.

This, in theory, could be done without affecting any inputs or outputs.

In addition the detection of password tokens could be done consistently in the config stage too and passed as a this.tokendetected

My view is that the providers should be as small as possible and use already derived and consistent data.

Just an idea.

I would see if I could do it myself but I'm not a python expert and don't want to break anything.

[adferrand]

I cannot agree more from a design perspective. In fact I have even in my backlog one step further: an instance of a provider should not be even tied to a specific operation. For now, the design of the project has been strongly driven by the CLI approach. You run a command, an entire python environment is set up, the operation associated to the command is done then memory is cleaned up.

Which means that from a Python library perspective, you create a provider for a specific domain + provider + action (through the client), execute the operation and forget about it. This is not very natural and you could expect in this situation that you can reuse the provider for another action and even another domain.

What you are proposing here goes in that direction in my opinion.

Now if we move to the implementation perspective, we have to take care of several elements of the existing code.

The thing is that all providers derive from a base provider that offers several methods explicitly relying on self.domain (eg. _*_name() methods) or implicitly because they do not pass the domain as parameter since it is expected to get it from the provider state (eg. all abstract methods basically).

On top of this, as you mentionned, another state of the provider is strongly related to the domain, it is the authentication. This one is harder to move out from the state, because it is certainly something you do not want to execute each time a new action is done, while being able to associate a "collection" of domain-authentication since you will need to use the correct one in a context where the domain becomes arbitrary for a specific action.

Of course the overal design have to be applied on each concret provider (~80 currently).

So moving out the domain/domainId is certainly something desirable in the long term in the project, but it requires a significant amount of time I do not have currently. However, if you feel motivated and have this time, I would gladely review a PR you would propose on that matter.

[paskal]

If you'll figure out an opt-in way of moving the providers into new paradigm (with clear benefits for the developers using it) and have instructions on how to do it, you'll have it done in no time.