Default not supported for socket input type

[apexskier]

From the documentation:

default property: You can define a default property for each input, containing a value to assign if no other input method was invoked (cli args or args file)

However, this doesn't work for sockets:

description: test for socket default
name: test
inputs:
  aSocket:
    socket:
      default: /foo
run:
  container:
    image: { ref: 'ubuntu' }
    cmd: ['echo', 'foo']

-
  Error(s):
    - inputs.aSocket.socket: Additional property default is not allowed
-

[chrisdostert]

Thanks, that doc link is from an example so it's a bit fast & loose.

The docs about opspec are meant to be authoritative, heres the section on socket typed parameters https://opctl.io/docs/opspec#socket-parameter .

That said, I know the point of this ticket is to ask why there is no default supported for socket input parameters.

This requires a story.

1. Originally, File/Dir typed inputs could be defaulted to a relative path. The relative path would be evaluated from the cwd of where the op was run.

2. We then started allowing File/Dir typed inputs to be defaulted to an absolute path. The absolute path would be evaluated as an embedded file/dir reference (/ is considered root of the current op dir).

   At the time we wanted to avoid supporting defaulting file/dir inputs to absolute path references resolved on the host machine because in general it's not portable. Think of a hosts file for example, it's in different places between windows & osx/linux. Also, root is different across windows & osx/linux (c:/ vs /) and so on..

   We realize this is non-ideal and aren't happy w/ it but don't know the best way to handle it. There are ideas but no glaring "right path forward".

3. When we added socket typed inputs, we didn't allow default altogether because we hoped whatever our "right path forward" we discover for 2. we could roll it for sockets as well and if we waited we'd avoid breaking syntax.

Takeaway is, let's figure out what's the best solution and roll it. What do you think?

[chrisdostert]

also, FWIW I think this will get rid of your need for passing in a socket alltogether https://github.com/opctl/opctl/issues/498

[apexskier]

I understand the general desire to avoid absolute to host filesystem file paths, that makes sense. I haven't come across a general need to do that. Allowing access to the docker network also doesn't make a lot of sense in a world where opctl runs on more than just docker (not relevant now, but maybe in the future?).

So, yeah, I think #498 will address my primary use case.

I do think this is still a valid issue. The "language" of opctl isn't orthogonal if default isn't supported. I think the core issue here is one of usability. If default was supported, this would output something about the file path not being a valid socket (because its absolute to the op directory), which would be more understandable because that's how paths work in opctl.

A tangent to this conversation, but related to paths, is the lack of support for home directory (~) relative paths. It would be nice to support that. (~/ is mapped to $HOME/).