Container.up()

[shykes]

Problem

When I call a function returning a Container, to run that container as a service, I have to run:

dagger call <MYFUNC> as-service up

That is 2 extra functions in the chain, which is cumbersome. It's common to write a wrapper function that returns a Service, for the sole purpose of typing:

dagger call <MY_OTHER_FUNCTION> up

But now I have to maintain one more function, with another name. It's also cumbersome and feels unnecessary.

Solution

Implement Container.up() as an alias for Container.asService.up().

This is similar to Container.directory() for example, which is a thin wrapper for Container.rootfs().directory().

[jedevc]

Maybe a separate issue, but Service.Up also has some issues (when calling from code, not from the CLI) compared to the previous dag.Host tunneling API we used to use.

Specifically - it doesn't return a Service type, it returns Void. This is a bit annoying, since there's no way to Stop it anymore.

[vito]

@jedevc My understanding is up is specifically designed for the CLI use case, and from code you should just other service APIs like Start and Stop. It's a little weird that the CLI DX creeped into the API, but pragmatism overrode idealism there

[jedevc]

@vito I don't think you can start a tunnel to the host without up though? So if I wanted to start a service, and then make a request to it without needing to start another container.