Adding New Feature, have an issue with spaces in PIDs

[DouglasBellew]

Hello!

I am attempting to add a new feature to Rapids.

I've added code to the ./config.yaml, ./Snakefile, ./src/data/streams/aware_mysql/format.yaml, ./tools/config_schema.yaml, ./src/data/streams/rapids_columns.yaml and ./rules/features.smk files using other features as sample guides. Everything seems to work well, except for when some of my PIDs have spaces in them (ex: 'Nagas iPhone').

With the spaces, when snakemake is trying to create its DAG, it fails because it looks like it splitting the PIDs on spaces.
(rule)

rule phone_sentiment_python_features:
    input:
        sensor_data = "data/raw/{pid}/phone_sentiment_with_datetime.csv",
        time_segments_labels = "data/interim/time_segments/{pid}_time_segments_labels.csv"
    params:
        provider = lambda wildcards: config["PHONE_SENTIMENT"]["PROVIDERS"][wildcards.provider_key.upper()],
        provider_key = "{provider_key}",
        sensor_key = "phone_sentiment"
    output:
        "data/interim/{pid}/phone_sentiment_features/phone_sentiment_python_{provider_key}.csv"
    script:
        "../src/features/entry.py"

If I add a ":q" parameter to the {pid} items, it looks like it properly quotes the data, but it fails on the next rule (join_features_from_providers) saying that it's missing (example) "data/interim/Nagas iPhone/phone_sentiment_features/phone_sentiment_python_rapids.csv" as an input to the rule.

The thing that's confusing for me is that I can run PHONE_ACCELEROMETER (the item I used as an example for my changes) using the same PIDs and it doesn't have any problems handling the spaces.

Is there some piece of code that I'm missing somewhere that allows the other sensors to be able to handle spaced PID data? I'd like to keep my code as close to the rapids standard code as possible.

Thank you,
Douglas Bellew

[JulioV]

Hi! PIDs are arbitrary so I'd not worry to much to make it work with PIDs that contain spaces. By convention we mostly use P01,P02 etc. However, I can open an issue to investigate why the join rule breaks.

Also, what sensor are your features based on? Keyboard? Adding a new sensor is ok and since it's working now that is great but in the future you can skip most of the changes to rules, containers and streams by just adding a new feature provider to an existing sensor