Vlad Neverov

Thanks for sharing your ideas, @Mateasek, I like the new architecture. Regarding backwards compatibility, can we use the `__future__`/`__past__` approach following the [PEP497](https://peps.python.org/pep-0497/)? Before the Cherab 2.0, anything that breaks...

Hi @Balazs-Peter, sorry for not replying for so long. There is a PR #400, which moves the line shape models to a dedicated submodule (see #396). I think it's better...

> I would personally wait with such changes for the new beam model which won't have backwards compatibility. I agree. Also, currently the beam's dispersion is calculated as a sum:...

Hi guys, I support the idea of an environment variable for the atomic data repository path, but I wouldn't include `OPENADAS` in its name. In the future, the atomic data...

> @vsnever the suggestion CHERAB_ATOMIC_DATA should be kept for the default path of Cherab's atomic data from the https://github.com/cherab/core/pull/377 you pointed out, shouldn't it? Okay, but then after updating to...

Anyway, I think `CHERAB_OPENADAS_DATA` is clearer than just `CHERAB_OPENADAS`.

> I looked quickly into https://github.com/cherab/core/pull/377 and why would it be problem to name the environment variable CHERAB_OPENADAS_DATA? I probably missed it, but there are no changes to the handling...

> @vsnever thanks for explanation. In this case I think using the CHERAB_DATA or CHERAB_DEFAULT_DATA is appropriate. Also, if you are already making such a big change in the https://github.com/cherab/core/pull/377,...

I like the idea. Regarding the folder structure, since subpackages may have their own documentation in the future, I think the demos and the docs should be separated at the...

Implemented in #400.