Can't define api_keys in spacefile

[AndreWohnsland]

When I try to define the api_keys argument under presets for a micro in the space file, I get:

Error: failed to do parse spacefile file, please check for correct syntax: yaml: unmarshal errors:
  line 9: field api_keys not found in type shared.Presets

Using following file:

# Spacefile Docs: https://go.deta.dev/docs/spacefile/v0
v: 0
micros:
  - name: fastapi-yay
    primary: true
    src: .
    engine: python3.9
    presets:
      api_keys: true

It's the same as in the Docs, and I've just installed the space CLI yesterday, so I think I am on the latest version.

Any idea what needs to be changed to get api_keys working?

[abdelhai]

hi

1. make sure your cli is up to date
2. make sure your spacefile (yaml) is correctly formatted

[aavshr]

that's strange, can you please share the details of your system?

Checking the script, it should install v0.0.7 by default?

yes the latest version should be v0.0.7 by default

I tested on a windows machine but I can't seem to replicate the issue.

Can you please try re-installing the cli? You can do that by running the same command. If that still does not resolve the issue, we will have to investigate more.

[AndreWohnsland]

Sadly, nothing changed. System is Windows, 64bit rel. 10, machine: AMD64 (Windows-10-10.0.19044-SP0).

I attached the console output here:

It's not listing the version as an option, trying it throws an error.

Edit: What's really odd, I just tried the installation on another win10 machine and there, space version works. But I have still no clue, why this does not work on this one here.

[AndreWohnsland]

I've seemed to pinpoint and solve the problem:

Using:

gcm space                                                                                                   

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     space.exe                                          0.0.0.0    C:\Users\Andre\.space\bin\space.exe

Showed that some older space script added a path to the system to a .space dir. Deleting that path from the env vars resolved it to point to the right destination:

gcm space                                                                                                   

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     space.exe                                          0.0.0.0    C:\Users\Andre\.detaspace\bin\space.exe

So it was probably using an older version of the cli.

Did you change the name of the folder some time in the past?

[aavshr]

ah ok, sorry for this @AndreWohnsland and thank you for finding the issue.

Yes, a newer version of the cli switched the name of the folder, but seems like there was an issue in windows where the older directory was not cleaned up.

[AndreWohnsland]

No worries, glad we figured it out. The installation on the other system got my gears grinding (I even copied the EXE from the other system). Now it works as intended, thanks.

May I take the chance and ask another question to you @aavshr? I've noticed that x_deta_api_key_name is not passed as a header when using the API keys anymore. Is there another new header, one under a different name? I liked this one under deta cloud, because you could also save the key name with your data entry. In case of a compromised key, you'd see immediately which key (name) was the one, and you could do according steps (delete the key). Currently, on space, it seems to miss that feature and I think (if it does not exist) it would be a great addition to the information gained when using the API keys.