[16.0][ADD] fs_storage_environment: make server_environment an optional dependency

[yankinmax]

PR is aimed to remove server_environment dependency from fs_storage in the scope of this issue:

• RFC: replacement of server_environment server-env#258

[ivantodorovich]

Thanks @yankinmax !

[ivantodorovich]

Do we need a migration script in fs_storage to get fs_storage_environment automatically installed on existing deployments? or is the auto_install: True enough?

[lmignon]

@yankinmax It's a breaking change on a critical addon. It would have been nice to have a discussion about this before making such a change. If someone using environment conf updates the fs_storage addon to the new version without having the fs_storage_environment into its addon path, it will break its installation without any error message explaining why. I'm a little bit afraid by such a change.
server_environment is also a depency for

• fs_attachment
• fs_attachment_s3
• fs_storage_backup

[lmignon]

If you remove the dependency on server_environment at the fs_storage level you also need to create glue addons for:

• fs_attachment
• fs_attachment_s3
• fs_storage_backup

But are we ready for such a change? I could manage it on my own projects but these addons are widely used. I think it’s important to gather as much feedback as possible before deciding whether to make this change across all versions or focus on the most recent one.

[yankinmax]

Hello @lmignon I completely understand the situation.
I've opened this PR, but still need to create a migration script to force the new module installation.

[sbidoul]

This part eval_options_from_env can stay, it is not related to server_environment.

[ivantodorovich]

Indeed

[lmignon]

Hello @lmignon I completely understand the situation. I've opened this PR, but still need to create a migration script to force the new module installation.

It’s important to keep in mind the different installation methods used by the different integrators. There’s no guarantee that the glue modules will be in the addon's path even if the new version of fs_storage is installed (this is currently the case when dependencies are managed by pip for exemple).

[ivantodorovich]

Hello @lmignon I completely understand the situation. I've opened this PR, but still need to create a migration script to force the new module installation.

It’s important to keep in mind the different installation methods used by the different integrators. There’s no guarantee that the glue modules will be in the addon's path even if the new version of fs_storage is installed (this is currently the case when dependencies are managed by pip for exemple).

How do you recommend we proceed?
We do need to remove this hard dependency

Usually auto-installing the newly created glue module and ensuring the transition is smooth is enough -- then, custom deployment details are a responsibility of each integrator. The same thing occurs when new python dependencies are added to existing modules if you're not using pip to install odoo addons.

[yankinmax]

Hello reviewers, after trying several approaches to write migration script we've decided to investigate further the server_environment removal from fs_storage.

I'll put this and related PR's to draft for now.
Thank you for taking time to discuss and review it.

[lmignon]

Hello @lmignon I completely understand the situation. I've opened this PR, but still need to create a migration script to force the new module installation.

It’s important to keep in mind the different installation methods used by the different integrators. There’s no guarantee that the glue modules will be in the addon's path even if the new version of fs_storage is installed (this is currently the case when dependencies are managed by pip for exemple).

How do you recommend we proceed? We do need to remove this hard dependency

Usually auto-installing the newly created glue module and ensuring the transition is smooth is enough -- then, custom deployment details are a responsibility of each integrator. The same thing occurs when new python dependencies are added to existing modules if you're not using pip to install odoo addons.

@yankinmax @ivantodorovich
On stable branches we try to avoid to introduce new dependencies but I'm not a fan of enforcing such a rule. Your refactoring could be a good idea and a new approach of server_environement also. To lower the risk and also automate the auto discovery/installation of the new glue addons declared as auto_install for people using pip, @sbidoul suggested and improvement into the lib used to package addons as standard python wheel. (sbidoul/whool#40). I think we'll find a path to lower the risk of such a change...

[etobella]

Well, we can keep the functions and leave the inheritance to the glue module, this way, nothing is broken. WDYT?

[lmignon]

Well, we can keep the functions and leave the inheritance to the glue module, this way, nothing is broken. WDYT?

IMO if we remove the dependency on the base module, we must do it at every level and create all the appropriate glue addon. I would like to maintain a clean and consistent dependency tree. I am by no means opposed to this split with server_environment. But if this is done, it must be carried through to the end to avoid inconsistencies.

[etobella]

I can do that on my PR, however be aware that with the current PyPi limitation that PR cannto be merged. also, why don't we do the logic in the module by detecting if a module is installed or not?

This way we only have one extra module (at least it is easier to merge it now)

[lmignon]

I can do that on my PR, however be aware that with the current PyPi limitation that PR cannto be merged. also, why don't we do the logic in the module by detecting if a module is installed or not?

This way we only have one extra module (at least it is easier to merge it now)

We've a temporary workaround for pypi so you could do it (And thank you for taking care of it ;-) . I prefer explicit dependencies since it's the only way to be able to test the code and to trace the dependencies.