This destination or ${install_dir}/venv is quite common, isn’t it?
But maybe it should be complete out of $data_dir / ${install_dir} ?
Because it will be backup by ynh_backup "$data_dir" and restored by ynh_restore "$data_dir"
But i will be always recreated, because reuse a existing venv may result in a broken state.
So it’s useless to put it into the backup archive, isn’t it?
On the postulate that $install_dir is for the binairies, dependencies, and basically all the software side of an app, IMHO the Python virtual environment should be out of $data_dir and in $install_dir/(.)venv.
That is very interesting, tell me more, please.
I only foresee a change of server architecture that could break a virtual environment, are there any other cases?
Yes it breaks if arch changed, but also if major python version changed.
This is the reason why i add --clear to the python -m venv call. I will just remove the whole venv directory structure. So it’s also useless to backup/restore it.
The utility is that builing a venv may take time, especially if some dependencies happen to be built locally, and most of the time the backup/restore happens on the same arch, so it’s totally reusable.
