@vito I think I may be hitting the

[short lynx]

🧵

[tidal dune]

yeah this sort of thing just doesn't work at the moment - you can't arbitrarily diff two sibling directories of the same layer, it has to be a diff between layers of the same path: https://github.com/shykes/dagger-go-sdk/blob/ef2c485e564574d3e89e0cb793f81f06218fa70a/go-sdk.dang#L268

we could maybe relax that restriction, but that's how it works atm (and how Directory.diff has always worked)

[short lynx]

Yeah, I introduced this problem while working around another problem - the changeset I return is highly sensitive to client workdir.

[tidal dune]

maybe you could work around it with something like directory.withDirectory(".", before).withoutDirectory(".").withDirectory(".", after)?

[short lynx]

In earlier version I didn't have this error, but instead you had to pick which of these 2 valid commands returned the wrong changeset:

1. dagger -m github.com/shykes/dagger-go-sdk call mod --path=./my/mod generate

2. cd ./my/mod; dagger -m github.com/shykes/dagger-go-sdk call mod generate

(side note: very cool that with new simpified workspace filesystem model, mod() can just default to path: "." and it works 🙂

but -> final changeset gets all Fed up

[tidal dune]

could be worth another attempt at having directories track their host origin path? unsure how the sands have shifted with modules v2 / workspaces / artifacts / etc

[short lynx]

Main difference is that now, we could focus on solving it in the Workspace API

Maybe there could be a Workspace.diff(other: Directory!): Changeset! ?

and if you return that changeset, there's extra tracking info which allows applying the changeset to the workspace ?

Note: @versed girder was just dealing with integration tests related to changeset exports, and how workspace-aware we want them to be (right now they are not at all, ie: dagger -W does not affect at all where the changeset is applied)

[fringe inlet]

fwiw we could also lift the restriction of not being able to diff things unless they are rooted at the same path. would require implementation updates (i.e. not just deleting the guard), but very doable now post-theseus

[short lynx]

ah!

Note in my case, that would fix my hacky workaround - but it would remain a hacky workaround (relying on Workspace.path leaking the real location of the workspace in the host system, which goes away in the workspace branch..)

[fringe inlet]

yep, just throwing it out there as an option so we don't get stockholm syndrome

[short lynx]

Yeah that is excellent news and we should take advantage of it regardless for sure

@tidal dune where did we leave past conversations around Workspace.stage(Changeset!) or whatever? Do we want to take that leap and allow modules to straight up write to files in the workspace themselves? It would be a big change for generate functions

It would be more like Container.terminal() I guess

[short lynx]

I think this 👆 would still be the safest thing to do

But we're back to the "immutable vs mutable" topic

[tidal dune]

that was right before PTO but i don't think we concluded anything, just tinkering and throwing ideas at the wall to see what sticks. The only context where I wanted a mutable Workspace so far was for LLMs writing changes back to the workspace, usually in isolated worktrees. I haven't hit any incentives to introduce that for plain modules

[short lynx]

Yeah, I also have very little appetite for a reinvention of this part of the model... Way too much on our plate already. I was happily developing my module and it "felt" right overall - except for the part where sometimes it patches the wrong place

So if there was a magical drop-in fix (ie. changeset tracking) that just made it work as-is, as a module dev I would be delighted right now