#Best practice note: I'm going to adopt
1 messages · Page 1 of 1 (latest)
Thanks @proud jackal
thinking about it a bit more I think my main objections is not even about the name dev but about moving dagger.json into a subdir - since this goes against one of our goals to make the CLI less verbose
Keeping things at the root allows me to not have to call -m $dir which takes a tiny chip away from the verbosity
Yes I agree, that's the goal of the PR mentioned above: make the -m ./dev optional basically
sorry I'm confused :/
move dagger.json to ./dev/dagger.json
Would'nt moving it inside of dev make it required?
Yes initially, but then a PR to dagger itself would change the default behavior when you omit -m. With the goal of making -m dev optional
Thanks for clarifying!
I am curious, did you already consider pipelines instead of dev? since that directory contains all your pipelines and maps nicely to the .github/workflows mental model?
yeah I did (and many other words) but from the perspective of a Dagger user today, I think it's too aspirational
(the contents of the directory don't mention the word "pipeline" anywhere)
Here's my litmus test - should we update this PR to use dev? 🙂
How is this pattern working out?
https://github.com/dagger/dagger/blob/main/dev/dagger.json
I notice that /dev/ is pretty widely used at the root of a project, so we might disrupt a lot of folks if we insist on it. I'd think something else like dagger/ or maybe or .dagger/ (or maybe pipelines/, but I don't have all the context)
too early to tell, it's an attempt at harmonizing 2 different patterns within our own repo (https://github.com/dagger/dagger/pull/7766#issuecomment-2195022396).
ah, okay, if the Dagger stuff can peacefully co-exist with other things in the dev/ directory, probably not an issue, right?
Since we hit a wall of solid bikeshedding when trying to solve the problem all at once (https://github.com/dagger/dagger/issues/7199) I'm taking a more incremental & experimentsl
approach
tbd 🤷🏻♂️
I was thinking about best practices and what to suggest to Paul Dragoonis and thought of this note from you I'd seen 🙂
Basically I acknowledge that this best practice is not fully baked, trying it out to build practical experience with relatively little risk, we can still break this in our own repo if needed