* replace `setup.py` with `pyproject.toml`
* move all Python package requirements to single `requirements.txt`
* remove checking Python package requirements in `CMakeLists.txt`
* move Python bindings to own dir (python/nmodl), fixes BlueBrain/nmodl#462
* add separate script for generating docs
* add `packaging/change_name.py` script to as workaround to enable both
  NMODL and NMODL-nightly wheels in CI
* update documentation and CI to reflect above changes

---------

Co-authored-by: Luc Grosheintz <luc.grosheintz@gmail.com>

NMODL Repo SHA: BlueBrain/nmodl@3acc935

* use cibuildwheel for creating redistributable wheels
* simplify CI pipeline
* update packaging docs

---------

Co-authored-by: Nicolas Cornu <nicolas.cornu@epfl.ch>
Co-authored-by: Luc Grosheintz <luc.grosheintz@gmail.com>

NMODL Repo SHA: BlueBrain/nmodl@347f786

* Throw error if passing directory instead of file to `parse_file`
* Add test for it

NMODL Repo SHA: BlueBrain/nmodl@f8c8d23

NMODL Repo SHA: BlueBrain/nmodl@b99ad62

Fixes BlueBrain/nmodl#1178

NMODL Repo SHA: BlueBrain/nmodl@26899cc

)

NMODL Repo SHA: BlueBrain/nmodl@b9d3033

The previous behaviour for

    KINETIC states {
         ~ x + y << 42.0
    }

was to print a warning and continue as if the line didn't exist. The new
behaviour is to throw an error, because it's unclear why ignoring the
line could ever lead to a correct translation of the MOD file.

NMODL Repo SHA: BlueBrain/nmodl@9292c18

* Format Python files with `black`.
* Enable `black` formatter.

NMODL Repo SHA: BlueBrain/nmodl@40aa0bf

What's meant is things like `celsius`.

NMODL Repo SHA: BlueBrain/nmodl@c8818c8

When encountering an indexed `COMPARTMENT` block:

    COMPARTMENT i, volume_expr { species }

All state variables are searched if they match they match the pattern
`"{species}[%d]"`. For each matching state variables, we obtain the
value of the array index and substitute the name of the array index with
its value in `volume_expr`. This is then stored in the array of
compartment factors.

Check that the resulting derivatives are divided by the volume
of the compartment.

NMODL Repo SHA: BlueBrain/nmodl@219a3ed

NMODL Repo SHA: BlueBrain/nmodl@9873e06

NMODL Repo SHA: BlueBrain/nmodl@2c7c3a9

NMODL Repo SHA: BlueBrain/nmodl@dd1c751

NMODL Repo SHA: BlueBrain/nmodl@4a15447

Co-authored-by: Nicolas Cornu <me@alkino.fr>

NMODL Repo SHA: BlueBrain/nmodl@c818f16

NMODL Repo SHA: BlueBrain/nmodl@98e6df2

…1234)

This can be reproduced by:

    cmake -B build && cmake --build build --target=generate_references

i.e. call `--target=generate_references` without building it first. It
would complain about missing `bin/nmodl`.

NMODL Repo SHA: BlueBrain/nmodl@735b11d

NMODL Repo SHA: BlueBrain/nmodl@593f38e

Store the forward and reverse rates in local variables, e.g.:
```
rate = 42.0
~ a <-> b (1.0*rate, 2.0*rate)
```
is converted to:
```
LOCAL kf0_, kb0_
rate = 42.0
kf0_ = 1.0*rate
kb0_ = 2.0*rate
~ a <-> b (kf0_, kb0_)
```

This solves a bug that assigning to `rate` between two reaction equation statements would mean the first line sees the value meant for the second line.

NMODL Repo SHA: BlueBrain/nmodl@868ce13

NMODL Repo SHA: BlueBrain/nmodl@bb5355f

In NRN we depend on the target `nmodl` to ensure that when we run `nrnivmodl -coreneuron` the binary `nmodl` exists. We need to also ensure that everything `nmodl` needs to works is present.

This fixes a dependency bug on certain copied files by making the target for copying the files a dependency of `nmodl`.

NMODL Repo SHA: BlueBrain/nmodl@b78c3f3

…dl#1241)

NMODL Repo SHA: BlueBrain/nmodl@df2343e

* Fix array variables.

These are the code generation changes required for:

    #2779

The solution is to fill `nrn_prop_param_size` with the number of
doubles, not number of variables.

NMODL Repo SHA: BlueBrain/nmodl@f6821ce

…dl#1244)

- If `-DNMODL_ENABLE_PYTHON_BINDINGS=OFF` then there is no need
  to generate AST and other wrapper classes for Pybind11.
- Using sympy-based solvers does not require Python bindings to
  be enabled. Avoid confusing warning when using nmodl binary.
- When someone tries to use the nmodl module via Python, the
  warning is still preserved.

```console
$ nmodl mod_examples/sparse.mod
[NMODL] [warning] :: Python bindings are not available with this installation
..

$ nmodl mod_examples/sparse.mod
$ python3.11 -c "import nmodl"
[NMODL] [warning] :: Python bindings are not available with this installation
```

NMODL Repo SHA: BlueBrain/nmodl@8eb88e4

- when neuron is built with nmodl then nmodl related files
  should be installed in <prefix>/ and not in <prefix>/nmodl/.data
- <prefix>/nmodl/.data is used when we build standalone wheels
- add one mod file using sparse solver - nmodl will automatically
  use sympy solver

NMODL Repo SHA: BlueBrain/nmodl@2fb037e

NMODL Repo SHA: BlueBrain/nmodl@2dc296d

It was dead code

NMODL Repo SHA: BlueBrain/nmodl@8285f26

NMODL Repo SHA: BlueBrain/nmodl@0ba94b7

… block (BlueBrain/nmodl#1248)

NMODL Repo SHA: BlueBrain/nmodl@b3dd6f1

Both the NEURON and CoreNEURON codegen need the same
code for printing all top-level verbatim blocks.

NMODL Repo SHA: BlueBrain/nmodl@41f0815

NMODL Repo SHA: BlueBrain/nmodl@311c814

NMODL Repo SHA: BlueBrain/nmodl@800d098

NMODL Repo SHA: BlueBrain/nmodl@3df34b9

NMODL Repo SHA: BlueBrain/nmodl@095fc75

NMODL Repo SHA: BlueBrain/nmodl@af7c882

NMODL Repo SHA: BlueBrain/nmodl@65a6678

NMODL Repo SHA: BlueBrain/nmodl@fc64097

NMODL Repo SHA: BlueBrain/nmodl@da2ae9f

NMODL Repo SHA: BlueBrain/nmodl@0186d19

NMODL Repo SHA: BlueBrain/nmodl@80d7b8f

Use `codegen --cvode` to enable.

NMODL Repo SHA: BlueBrain/nmodl@25da002

The race is cause by the fact that two targets exist to copy the Python
files. The first one because of `cpp_cc_build_time_copy` without
`NO_TARGET`. The second because of the:

    add_custom_target(nmodl_copy_python_files ALL DEPENDS ...)

The solution is to not create the per file target by passing
`NO_TARGET` to `cpp_cc_build_time_copy`.

NMODL Repo SHA: BlueBrain/nmodl@1f0c5c1

The code for the code-generator NMODL is itself generated from Jinja
templates. This requires CMake integration to ensure it happens
automatically.

The following has been changed about the integration:

  * The CMake code needs a list of the generated files. This list is
    stored in a CMake file and included. This file must exist before
    running `code_generator.py` to generate the NMODL code, because the
    command to generate the files needs to know which file it will be
    generating. Therefore, we split the script into two phases: one to
    generate the list of generated files, and another to generate the
    files.

  * The list of generated files depends on the build flags. Therefore,
    this file (`code_generator.cmake`) can't be checked into the Git
    repo. The `code_generator.cmake` is created during the configure
    phase, and now lives in the build directory.

  * CMake code was lifted from `src/language/CMakeLists.txt` to the
    top-level `CMakeLists.txt` to avoid any scoping issues for the
    lists of generated files.

  * Removed pattern of yielding tasks while creating a list tasks in
    favour of returning the list of tasks directly.

NMODL Repo SHA: BlueBrain/nmodl@49fdfe6

* Lower `visit_protected_statement`.

The code is lowered into the CoreNEURON side, because
NEURON can't use the same OpenMP system.

* Lower `print_atomic_reduction_pragma`.

This method is specific to the CoreNEURON implementation of
`visit_protected_statement`.

NMODL Repo SHA: BlueBrain/nmodl@ea94748

The previous implementation would apply the transformation to children
of the node in the AST. Hence, if the root was `sp.Derivative` it would
fail.

This commit adds a fix and the tests.

NMODL Repo SHA: BlueBrain/nmodl@16b5f95

* Fix thread_variable conditions.

* Support PROTECT via `_NMODLMUTEX{,UN}LOCK`.

* Add tests.

NMODL Repo SHA: BlueBrain/nmodl@96299cb

NMODL Repo SHA: BlueBrain/nmodl@a851a1b