2021 02 15 Open NEST Developer Video Conference

previous | list | next

Agenda

1. Welcome
2. Review of NEST User Mailing List
   • documentation of items asked for on the mailing list has to be made more prominent
   • all messages handled
3. Project team round
4. In-depth discussion
   • t.b.a.

Mailing list

• https://nest-simulator.org/mailinglist

Project team round

Here we discuss topics that need broader attention, for example questions that came up but are outside a single project's scope, larger planned changes/PRs that affect all teams or pending work that is blocked by external factors.

1. Models / NESTML
   • working on STDP testcases
2. PyNEST
   • nothing to report
3. Kernel
   • waiting for reviewers to merge instrumentation PR
   • #1549 "revised RNGs" now under review
4. Installation
   • nothing major to report
   • discussing different ways of dependency/environment specifications
5. Infrastructure
   • when to switch on the Github actions on master
   • run Travis in parallel for some time to compare results, then turn off Travis.
6. Documentation
   • much progress on doc build system, pynest examples, RNG documentation
   • fixes and maintenance
7. EBRAINS
   • nothing to report
8. (Feature) Random number generation
   • see kernel
9. (Feature) Automated Testing
   • nothing to report
10. (Feature) Extension Module System
    • nothing to report

In-depth discussion

Different ways of dependency/environment specifications

• extractor for dependencies (a la grep import)
• many different environments required
• #1612 is still open, but how to document for the different cases? Currently different descriptions for docs, tests, build, runtime, …
  • multiple requirements files needed?!
    • doc system
    • build-time environment
      • test environment
    • nest-server (always built, but doesn't run without runtime dependencies)
  • which packaging to support? (conda, native(apt,pip), brew?)

What use-cases do we see, e.g. on the mailing list

• run-only
• build nest-simulator locally
• build documentation
• deploy on resources (e.g. EBRAINS)

One setup that contains all

• low maintenance
• many components not needed separate X for each UC
• difficult/more complex for many users

Is a central specification possible from which different env specs can be built?

• not want to maintain own package database for different names in brew vs. apt vs. conda vs. …
• pip-only solution possible? pip install cmake
• security updates usually do not come into user-built environments (at least not by admins)
  • need to leave this choice to the user
  • updating environments is possible (conda env update)
• what needs to be possible by "power-users"?
• large combinatorial space is very difficult to test
• one path that works for all and let users deviate from that.