I believe in prep command @dirmods was previously replaced with paths relative to the working directory of modd. e.g.: "./packageA", "./packageB" ??
It seems that currently it outputs some paths relative, but without the ./. Other paths are given as absolute paths. This totally breaks common use cases such as:
**/*.go {
prep: go test @dirmods
}
go test needs a relative path prefixed with ./, or otherwise the provided argument is seen as import path. Absolute paths won't work either. It's either a ./ relative to working directory, or and import path that are supported. It would be nice if modd could return to it's original behaviour.
Drat, this slipped through during a recent rewrite to handle symlinks that might fall outside the current directory. A fix is inbound shortly. Thanks for testing and reporting these issues.
I believe in prep command
@dirmods
was previously replaced with paths relative to the working directory of modd. e.g.:"./packageA", "./packageB"
??It seems that currently it outputs some paths relative, but without the
./
. Other paths are given as absolute paths. This totally breaks common use cases such as:go test
needs a relative path prefixed with./
, or otherwise the provided argument is seen as import path. Absolute paths won't work either. It's either a./
relative to working directory, or and import path that are supported. It would be nice if modd could return to it's original behaviour.