#Project commands

1 messages · Page 1 of 1 (latest)

valid egret
#

@solar mirage, have you thought of a way to support mixed languages in the same project?

#

Project commands

solar mirage
#

Yes: https://linear.app/dagger/issue/DAG-1420/support-hierarchies-of-projects

There's a few possibilities in terms of how to model it. One is that you could "aggregate" projects together. So you could have a python and a go project and combine them together into one merged schema/cli.

And maybe that's from being able to specify multiple projects, or maybe you can have a dagger.json that references multiple projects, etc. TBD

valid egret
#

How do you run dagger do with the demo?

#

The go runtime is failing to build

#

Oh, I got confused... the TUI shows a red ERROR on the command because it exits with non-zero code. I was actually after the available commands and they're there. We should return 0 when listing.

#

I also got confused between -c and -p (and there's --workdir as well). I was looking at the two demos as two projects.

solar mirage
solar mirage
# valid egret I also got confused between `-c` and `-p` (and there's `--workdir` as well). I w...

Yeah I had an issue for consolidating these. Workdir in particular no longer needs to exist I don't think. I ended up just tracking that as part of my current PR for supporting host dir integration w/ commands since it ties fully into that: https://linear.app/dagger/issue/DAG-1433/cleanup-and-consolidate-the-various-project-related-paths

I think the concepts behind --project (the project "root" dir) and --config (the subdirectory containing actual code for the commands) probably still need to exist in some form or another, in order to deal with the problem of project code being a subdir but still needing go.mod/package.json/pyproject.toml/etc. in a project root dir.

But they at least could be named better (I chose config because it's currently where you have to put dagger.json, but in retrospect it's a bad name)

And even better I think that we could possibly reduce down to just a single flag. One idea would be to leave dagger.json where it is (in the dir with the project code), but add a field that lets it specify the project root (e.g. "projectRoot": "../.."). Or you could do the inverse and require users to always put dagger.json in the project root and allow it to specify code subdirectories. Or we could do something like automatically set the project root to where a .git dir is, etc. etc. etc.

I'll add a note about this to the backlog issue for re-adding dagger.json support to the CLI, would make sense to tackle there.

valid egret
#

Yeah, for example with pyproject.toml it marks the root of the project (sdk/python), but inside it you can see:

packages = [
    { include = "dagger", from = "src" },
]

Which references sdk/python/src/dagger. So when you install from sdk/python, what you get is sdk/python/src/dagger in your virtual env.

#

So you could default the code (main.go) to be next to dagger.json, but allow setting a different path like src for it in the .json file.

#

If I run poetry in a subdir of sdk/python, it'll search for a pyproject.toml up the file tree.

#

But you can also set poetry -C xxx to make it specific, including if you're in a parent dir instead.

#

This seems like what I usually see with other commands.

#

TL;DR: the equivalent would be using the dir with dagger.json to be the project dir, and allow setting the src context from there.

#

However in our use case, since we want to load the root of the repo in ci and demos, you'd have a single dagger.json with multiple "projects".

#

I'm still confused by the term "project"! 😂

#

Scratch what I just said. 👉 I meant what you said with projectRoot.

valid egret
#

What would be a good name for a base class? class Main(dagger.Dagger):? dagger.CommandGroup is too long, dagger.Group is too generic… this would match strawberry.type.

valid egret
#

I'm thinking dagger.Commands with dagger.Server:

from typing import Annotated
import dagger

class Project(dagger.Commands):
  async def build(self, repo: Annotated[str, "The git repo URL"]) -> str:
    """Build the binary."""
    return await self.client...

app = dagger.Server(Project)

Project can be any name. Up to the developer. dagger.Server and app I'm more unsure, but it can be reused later for other types of extensions, even a strawberry schema object directly. I could hide that line and support a single function but that'll lead to multiple ways of doing things depending on your needs and I'm not sure it's worth it, although other projects (e.g., Typer) do that.