Currently, when compiling a program with Scriggo, if a path is imported that is provided both as a Go source file and as a native package, the Scriggo build takes the Go source file into account, ignoring the native package entirely.
This behavior can be ambiguous and create unexpected situations.
One option is to return an "ambiguous import" error in these scenarios, thus clearly indicating that you are attempting to do something ambiguous.
What the Go compiler does
For a useful reference, this is the behavior of the Go compiler. Consider this scenario:
.
├── exec
│ └── a.go
├── go.mod
└── main.go
where main.go contains:
package main
import "os/exec" // <- the ambiguous import
func main() {
_ = exec.A
}
the go.mod contains:
and exec/a.go contains:
If the package is compiled with:
this error is returned:
ambiguous import: found package os in multiple modules:
os (/home/user/...)
(/home/user/.../go1.26.1.linux-amd64/go/src/os)
Currently, when compiling a program with Scriggo, if a path is imported that is provided both as a Go source file and as a native package, the Scriggo build takes the Go source file into account, ignoring the native package entirely.
This behavior can be ambiguous and create unexpected situations.
One option is to return an "ambiguous import" error in these scenarios, thus clearly indicating that you are attempting to do something ambiguous.
What the Go compiler does
For a useful reference, this is the behavior of the Go compiler. Consider this scenario:
where
main.gocontains:the
go.modcontains:and
exec/a.gocontains:If the package is compiled with:
this error is returned: