Here is another question: most of my

[plucky pendant]

cross module dependencies actually make these modules more complex.
Could you expand on that part?

instead of making a separate poetry module, it's gonna be a "submodule" of Python
We had a similar conversation last week where python's package managers make a good case for a module interface

[granite harbor]

Could you expand on that part?

There are two issues I noticed:

1. Duplication

Some of the API needs to be duplicated if you want to expose some of the features the underlying module has.

For example: https://github.com/sagikazarmark/daggerverse/blob/main/golangci-lint/main.go#L109-L143

In order to be able to manage cache volumes of the underlying Go module, the golangci-lint module needs to expose those functions as well.

Another example is the constructor: https://github.com/sagikazarmark/daggerverse/blob/main/golangci-lint/main.go#L36-L46

Would be nice if I could just pass an initialized Go module to the GolangciLint constructor, but that's sadly not an option.

2. Another example I have right now is with Poetry and Python:

Some of the initialization steps (specifically the ones using pip) has to be deferred.

Similarly to the Go example, I want to allow mounting a cache volume for Pip. In order for that to be effective though, I can't add poetry installation steps in the constructor (because any subsequent WithCacheVolume call would be after that).

So part of the initialization needs to be moved somewhere else (eg. a private container function that needs to be called first in module actions).

It's not the end of the world, but it makes the module more complex.