The purpose of `dagger generate` is to

[astral sequoia]

I'm not sure +generate needs to be tied to files being source controlled.
It's very nice to be able to invoke dagger generate anywhere before your launch your IDE and not have to think about what's source-controlled and what isn't.

[pallid tangle]

well, that's the purpose of generate 🙂
I don't remember if we came up with the final wording for the action of exporting files on the host, from a module. In some way that could be part of ship as ship is about functions that have a side effect.
See for instance https://github.com/dagger/dagger/discussions/11653

A generate function is to generate source-controlled assets in your project

It's very nice to be able to invoke dagger generate anywhere before your launch your IDE and not have to think about what's source-controlled and what isn't.
If you have a generate (or whatever the name) function returning a Changeset I guess that's roughly similar, a dagger call generate works.
Out of curiosity what kind of files you need to generate before to launch an IDE?

For sure I can add a +no-check but the goal of all those verbs (check/generate/ship/...) is to organise in a (kind of) opinionated way the different tasks to be done on a project.
generate is one of them, for a specific purpose.
But to be able to create and export resources on the host that are not intended to be source-controlled is also one, just it's a different one we haven't yet covered

[astral sequoia]

We use buf and protoc to generate sources based on proto files. We choose not to commit generated files.
They're humongous compared to the source, would make resolving conflicts worse, a bunch of other reasons, including personal preference.
It's different from +ship, not really a project artifact.
Being able to to invoke dagger generate to make IDEs happy is handy, we can use the same instructions, regardless of what other generators we might use.

a more involved alternative would be for dagger to see if generated files are source-controlled, but that's way too complicated.

[hoary quiver]

maybe we can leverage native support for gitignore

[astral sequoia]

Not sure how much work that would be. Without looking at the code pragma-based control seems a lot easier.
Having said that gitignore has an advantage if you want to reuse the same dagger module to build different projects.

[hoary quiver]

I would rather not complicate the pragma system with a no-check

Let's call it our plan B 🙂

[astral sequoia]

gitignore is def better 👍

[pallid tangle]

I don't know. I understand why, but it would mean a check based on generate will pass with a changeset that is not empty, with a changeset not containing not gitignored files.
The main logic is that if a check on a generate function passes, then to call the function should not have any effect. And if a check on a generate function doesn't pass, to call the function should make the check pass.
It's like if I have a fmt function, and a check-fmt function. If check-fmt doesn't pass, to call fmt should allow check-fmt to pass.
A check on a generate function means "you have to run it to be in the right state" if it doesn't pass, or "everything is already generated, all good" if it passes.
If we introduce gitignore there, we break that. The check might pass but the files are not generated. The check then is useless.
I think generate and check should work together (that was how we imagine it from the start). And if something doesn't fit it should be (until we introduce an extra verb) a simple function. That would be the way to break the check-generate relation.
At least that's my current feeling.

[hoary quiver]

FYI I'm preparing a github discussion thread so we can continue there

[astral sequoia]

I see a distinction between fmt and generate though. fmt by its nature modifies something that already exists.
generate creates files, which can only be checked for changes if you happen to keep them source-controlled.

[hoary quiver]

https://github.com/dagger/dagger/discussions/12931

[pallid tangle]

I came up with a new suggestion that I think could work, doesn't introduce new concepts, and allow to not have a check for a generate function: to use the already existing ignoreChecks configuration.
My understanding is it would solve the issue, without to breaking it, and without to introduce a new pragma (and by the way it's a different view on it as it would be a consumer configuration)

[pallid tangle]

PR has been updated with tests to ensure ignoreChecks is correctly applied on the check list, so including the ones created from generate functions

[hoary quiver]

what is ignoreChecks?

[pallid tangle]

This is an existing configuration in dagger.json on toolchain modules so when we reference a module as a toolchain we can ignore some of the checks the module is providing

[hoary quiver]

ah ok