- csv-data sets will now be corrected, no matter if the "for"-value is: 1234567, "1234567" or '1234567'
- depending on "isregex" value in csv first exact matches, second regex matches. So it is safe that if double matches occur, exact matches always wins.
- debug for CSV row read implemented
- updating readme to newest development
- Füge CSV-Import über csvPath-Konfiguration hinzu
- Implementiere Regex-Matching mit isRegex-Flag (YAML & CSV)
- Erstelle unified cache für YAML- und CSV-Einträge
- Wildcard-Replacement mit dynamische Beschreibungen
- Erweitere Logging für bessere Debugging-Möglichkeiten
Neue Features:
* CSV-Dateien können parallel zu YAML-Beschreibungen verwendet werden
* Regex-Unterstützung ermöglicht Pattern-basiertes Matching
* Wildcards wie {TONE} werden in Beschreibungen ("add"-Werte) ersetzt
* Vollständige Abwärtskompatibilität zu bestehenden Konfigurationen
Technische Verbesserungen:
* Unified cache-System für bessere Performance
* Korrekte Iteration über Config-Objekte mit default-Parametern
* Robuste Fehlerbehandlung für CSV-Import
* continue statt break bei fehlenden scanFields
Einschränkungen / known limitations:
* Keine explizite Behandlung von Duplikaten
* Standardverhalten ist „last one wins“, d. h. das zuletzt passende Descriptor-Objekt überschreibt den Wert
* Wenn mehrere CSV/YAML denselben Schlüssel liefern, hängt das Ergebnis von Lade- bzw. Listen-Reihenfolge ab
Without this change, many warnings like this will be generated while running pytest:
```
test/test_template.py:3
/build/source/test/test_template.py:3: DeprecationWarning: invalid escape sequence '\/'
"""!
```
This can also be seen when manually running python with warnings enabled.
This happens because the comment uses a multiline string and Python interprets the backslash in the logo as an escape character and complains that \/ is not a valid escape sequence. To fix this, prepend the string with the letter r to indicate that the backslash should be treated as a literal character, see https://docs.python.org/3/reference/lexical_analysis.html#index-20.
I also applied this change to all the comment strings since that shouldn't break anything and to establish it as a pattern for the future so this problem hopefully never happens again.
This is what I did specifically:
- Change the comment at the top of bw_client.py and bw_server.py to start with `"""!` since that seems to be the pattern here
- Search-and-Replace all occurances of `"""!` with `r"""!`
- Manually change the strings in `logoToLog()` in boswatch/utils/header.py