#This is fun 🙂

1 messages · Page 1 of 1 (latest)

vivid lagoon
#

interesting...
just tried to see what else it can do.
tried:

ctr1=$(.container | from alpine | with-exec echo,hello,world)
$ctr1 | stdout

didn't work.
am I doing it wrong? or am I trying something it's not intended for?

trim halo
#

we don't have variables hooked up yet. but subpipelines do work

#

try eg. mounting the output of a pipeline as a directory into another pipeline

#

dagger shell -m github.com/dagger/dagger -c '.container | from alpine | with-file /bin/dagger $( cli | binary ) | terminal'

barren cosmos
#

This may sound a bit facetious I know (and not intended to be by any means), but isn't this the kind of "artisanal" scripting Dagger was built to avoid? 🤔 🥹 😜

vivid lagoon
#

Subpipelines look very useful, definitely a lot more flexibility compared to regular dagger call.
Interestingly with-file parameters are space separated.

I wonder if using starlark for scripting would make it more approachable. It would especially powerful if you could import sources from the module.

vivid lagoon
#

For a second I thought it could make using interfaces easier, unfortunately this didn't work:

// should this work?
// dagger shell -c 'info $(python-project "p1")'

package main

import (
    "context"
    "fmt"
)

type Daggerscript struct{}

type Project interface {
    DaggerObject
    Name(ctx context.Context) (string, error)
    Lang(ctx context.Context) (string, error)
}

type PythonProject struct {
    PName string // +private
}

func (p *PythonProject) Name(_ context.Context) (string, error) {
    return p.PName, nil
}

func (*PythonProject) Lang(_ context.Context) (string, error) {
    return "python", nil
}

func (m *Daggerscript) PythonProject(name string) *PythonProject {
    return &PythonProject{PName: name}
}

func (m *Daggerscript) Info(ctx context.Context, project Project) string {
    name, _ := project.Name(ctx)
    lang, _ := project.Lang(ctx)
    return fmt.Sprintf("Project '%s', lang: '%s'", name, lang)
}
ember pecan
#

This is fun too 🙂

demo.gif
trim halo
trim halo
arctic peak
# vivid lagoon interesting... just tried to see what else it can do. tried: ``` ctr1=$(.contai...

The value of $ctr1 has to be sent as stdin to stdout, so this should work:

ctr1=$(.container | from alpine | with-exec echo,hello,world); ..echo $ctr1 | stdout

Note that if in interactive mode, the var needs to be defined in the same prompt where it's used. That's the part that's not "hooked up" yet. No such restriction otherwise. Also, the .. in ..echo is a workaround (temporary) for the shell's echo (instead of a function called "echo"). We need to bikeshed how to access those built-ins.

trim halo
#

Ah I didn't realize the vars were hooked up already!

arctic peak
#

Yeah, since the beginning 🙂

trim halo
#

I think we should have .echo as a hidden alias to .print, it's just so familiar for people.

#

or maybe .print needs to be its own thing, eg. .container | .print (print object contents).

vivid lagoon
#

will there be any way to pass args by name in the shell? I kinda like the explicitness the CLI requires. It's also helpful when you have a function with optional arguments

trim halo
#

yes, that is supported also

#

well, it's supported for optional arguments. It's not supported for the required arguments, because it would be difficult to support both modes at the same time

arctic peak
#

It's technically possible but I think it could be a bit confusing. If you have 3 required arguments and 2 optional, and write the second required argument as a flag, it means your 2 positional args would relate to the first and third required function args. One alternative would be to either make it all flags or mixed positional and flags. So if the function has required args but you don't provide any positional ones, we could then check for flags before failing.

trim halo