Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Per-Device {instance,class} user-configurable settings

Aperta
  • Qualcosa non va?
#293 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
json, python, yaml
Ambito
developer-experience, tooling

Direzione di ricerca

Non sono stati identificati file di implementazione, test o punti di ingresso. Inizia risolvendo il formato di configurazione, la corrispondenza tra classi/istanze, l’ereditarietà, l’unione, la validazione e i valori predefiniti descritti qui; il lavoro sarà considerato completato quando sarà definito un framework concordato e implementabile, con strumenti e test di supporto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

There are a certain number of per-ophyd.Device configuration settings that users will never be happy with our choice of defaults. While discussing this, our primary example has been device tab whitelists.

As different users have different (legitimate) needs and preferences, @ZLLentz and I came to the conclusion that it's sensible for us to:

  1. Allow the user to configure these without our intervention or a bug report/pull request/release cycle
  2. Provide a general framework for these configuration settings.
    • Our goal with the framework should be the ability to support any of the following that we agree would be good to include - even if those aren't added on day 1.

User-configurable settings

Some potential things that we would add:

  • Tab completion settings
  • Kind settings (a configuration file overlay, of sorts)
  • User interface icons
  • Preferred user interface layout or display filename potentially (for device.screen())
  • Tweakable device representations (@ZLLentz has an ophyd branch sitting somewhere with Jinja2-based reprs of devices. These templates could be stored in code as defaults and updated as part of config files)
  • Device name aliases (then again, rereading https://github.com/pcdshub/hutch-python/issues/213 I somewhat prefer that)
  • Preset positions (we already have a supported YAML format for this; I think we will decide to leave it alone)

Defaults

  • We should provide a configuration with sensible defaults.
    • Good settings shared among many hutches could make their way back into the defaults.
  • It should be possible to inherit from and modify the default configuration.
    • This indicates we should have some ability to merge any/all configuration settings in a standardized way

Format?

Providing a configuration file of a common format (explicitly not Python code) such as JSON or YAML seems to be superior for the following reasons:

  • Easier to generate from code
  • Easier to validate from code
  • Less tied to API changes (but not entirely shielded, of course)
  • Syntax errors or API changes won't break loading entirely

Device classes and instances

Why support classes as well as instances?

  • Requiring the user to copy/paste configuration for every instance of EpicsMotor would be nonsensical (and generate a large config file, at that)

Why not just support classes and not instances?

  • Our goal in the end is to provide granular configuration for each and every device.
  • It's impossible to confidently say "the user will never want different settings for two of the same device class". (We also haven't figured out exactly all of the configuration settings we'd like to support yet, at that)

Inheritance?

Questions for now, as this requires more discussion:

  • How does inheritance apply to configuration?
  • In some cases, we may want to inherit and add to base class configuration
  • In some cases, we may want to start from scratch
  • Merging configuration from an inheritance tree could be messy.
  • To what level do we want to support this without it becoming too confusing to find out where settings are coming from? Is there a middle ground or is it all-or-nothing?
  • For ophyd.Kind specifically - how do you deal with conflicts?
  • What implications are there for an ophyd.Component which has a class/instance configuration, and when the parent device has conflicting class/instance configuration settings?

Tooling

We should provide some additional tooling that performs the following:

  • Configuration validation
  • Generating defaults
  • Merging configurations
  • Generating ophyd.Device Kind trees so that the user can tweak them easily
Lingua principale
Python
Stelle
1
Fork
18
Merge medio
5g 14h
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pcdshub/hutch-python

Tutte le issue di pcdshub/hutch-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.