CLI: calling 'export' just prints 'true' about dagger HOT 6 OPEN

dagger call consistently prints the results of functions. When you use --output it actually uses export underneath, and reports the absolute path back to you. It's also a persistent flag so you can put it closer to a matching input if desired.

Remember this?

• #6321

There's also an issue called "Update Bool -> Void" (DEV-2774) since it's no longer necessary that some functions like Export return a boolean. You can just return Void and check for error. In this case though, if export: Void!, rather than seeing true you'll end up seeing nothing actually.

But #6357 was supposed to replace using export in the CLI, and I hoped the difference in output would help nudge people towards -o as the goto for saving any output from functions to the host. However we're showing more of export in the docs rather than -o.

If we make it so dagger call func export --path PATH in the CLI does the same as dagger call func -o PATH, it's going to be even more ambivalent when to use one vs the other. My preference is to adjust our docs and help support to favor -o because of consistency.

I do understand how using export can also be more recognizeable since it's in the core API and users have been using it before modules. We may also end up deciding to do something about these side-effect functions, like #6321. In the meantime, if there is consensus to make export the same as -o, there's a bit of pre-requisite work to support it which is the same for another issue related to detecting "sync".

from dagger.

I think export returning the path is perfect. Especially combined with #7132 : when path argument is not set, export could create a tempfike/tempdir and return that.

Thanks!

from dagger.

Alternatively, we could have it show the same output as the --output <path> option:

 ~  dagger -m github.com/shykes/daggerverse/[email protected] call container --output ./wolfi.tar                                                     Fri 19 Apr 2024 11:20:34 AM EDT
Saved output to "/home/kpenfound/wolfi.tar".

from dagger.

If we make it so dagger call func export --path PATH in the CLI does the same as dagger call func -o PATH, it's going to be even more ambivalent when to use one vs the other. My preference is to adjust our docs and help support to favor -o because of consistency.

These are two separate problems, which we should address separately:

• Problem 1: there are two ways to do the same thing: -o and export. Do we like the current UX that results from this, and if not how do we improve it in the future?
• Problem 2: today people use export (whether we like it or not), and it prints true which is confusing. The underlying API returns a boolean but it's not even documented why. How do we fix this?

It's better to decouple, because even if tomorrow we decided to deprecate export to solve problem 1 (which by the way I disagree with), it would take a long time to transition. Meanwhile, we can probably solve problem 2 very quickly.

Remember this? #6321

I do remember, but then we decided to embrace functions with side-effects: export, terminal, up. That makes the role of -o quite ambiguous. Even if we deprecate export in favor of -o, then that would still leave the other functions with side effects. This inconsistency is why I have been avoiding -o personally: I prefer to stay consistent, even the current system is not perfect.

dagger call consistently prints the results of functions.

For the record that's not completely true :)

from dagger.

In this case though, if export: Void!, rather than seeing true you'll end up seeing nothing actually.

That would be an improvement. I think we should do that in any case.

If we make it so dagger call func export --path PATH in the CLI does the same as dagger call func -o PATH, it's going to be even more ambivalent when to use one vs the other. My preference is to adjust our docs and help support to favor -o because of consistency.

I think we should ignore that. If we deprecate export in the future, so be it. We'll cross that bridge when we get to it.

In the meantime, we should make the current experience with the current API and CLI, as good as possible. I think it's acceptable for the CLI to make special cases when printing results, as long as it improves the user experience.

In this case, I think it would improve the UX for export to print the same thing as -o. A future deprecation of export (which is very much not a sure thing) is irrelevant IMO.

One more argument in favor of printing the path at export: it would make #7132 easier :)

from dagger.

These are two separate problems, which we should address separately:

• Problem 1: there are two ways to do the same thing: -o and export. Do we like the current UX that results from this, and if not how do we improve it in the future?

I think there’s a need for both, but I don’t like the Venn intersection here. For now I’m just suggesting to nudge towards -o via docs, support, etc. In this regard, not in exclusion of the rest!

• Problem 2: today people use export (whether we like it or not), and it prints true which is confusing. The underlying API returns a boolean but it's not even documented why. How do we fix this?

I’m totally on board to make the output match what -o does. I think it’s useful to show the absolute path where the file was saved (that’s why I added that 😛).

Additionally (and separately), I want to change their return type from Boolean → Void anyway.

It's better to decouple, because even if tomorrow we decided to deprecate export to solve problem 1 (which by the way I disagree with), it would take a long time to transition. Meanwhile, we can probably solve problem 2 very quickly.

Yes, of course. 👍

But to be fair, I think the idea to deprecate export was because of confusion and over reliance on saving assets to the host thus missing out on many benefits. Not because of -o. It’s just correlated.

Remember this? #6321

I do remember, but then we decided to embrace functions with side-effects: export, terminal, up. That makes the role of -o quite ambiguous. Even if we deprecate export in favor of -o, then that would still leave the other functions with side effects. This inconsistency is why I have been avoiding -o personally: I prefer to stay consistent, even the current system is not perfect.

I don’t put terminal and up in the same bag with -o and export because they don’t return something that you’d want to “save”. I know I used the term “side effects” but I don’t use that as any kind of rule or anything. up returns Void but even if export also returns Void, by default, -o should do nothing as a baseline (and not a rule). On top of that, since export does actually produce an “output”, we make a special case to handle it.

Intuitively it makes sense. Users don’t know or care if it's a Void or not. But it makes sense that you can "save" a Container, Directory or File to disk, but not a Terminal or service.

Now that I’m thinking about it, why doesn’t export return a String instead of Void, with the absolute path that was exported? Like publish does with the full address including the digest? 🤔

Then -o would be just a shortcut, alias or convenience to export --path, not doing any special handling on the output (just query selection).

dagger call consistently prints the results of functions.

For the record that's not completely true :)

I regret using those words as they don’t represent what I meant at the time. 😄 I was actually talking about the --output flag specifically, and meant that it consistently saves the result of a function to a path on the host.

The special cases are technically functions that return a Terminal, Container, Directory or File:

• Terminal behaves like a side-effect function, and these “conceptually” return Void, like up. In that case the --output of Void should be a no-op (actually, it's possible Void produces an empty file rather than doing nothing, I haven't tested this), although in the case of Terminal, -o doesn’t even come out to play so it really has no effect.
• The other three amigos are Boolean but that’s because we didn’t have Void at the time. Conceptually though, even in this case, they’re still an exception because in the POV of --output, there is in fact an obvious field to save these objects to the host, and that’s export. So we alias that instead. If we change to String, it’s still the same special treatment, just more trivial.

Other than that, whatever the output is, if you add -o, it’ll save that output in a file.

I’ve clarified that I was talking about -o, but just to add context to these as well:

custom object types Print an error + usage message

That’s actually meant to be temporary until we can show an object’s scalars. And if there’s any better way to print something, I’m open to ideas.

core object types: Container, Directory, File, Secret Print an info message (eg. "container evaluated") and usage message

That’s just to avoid neither returning an ID nor showing nothing, but when we’re able to print custom objects like the previous point, I plan on doing the same here. In that case, if you add -o, for consistency it should save that output rather than aliasing export. Basically today, in these types, if you have -o it selects export. If you don't it selects sync. With this change, both would select some of the children.

TL;DR

Here’s what I suggest:

• Change export to return String, with the absolute path that it exported to (like publish).
• Simplify the -o implementation in dagger call to take advantage of that output, rather than the other way around.

from dagger.