Modifying a module's imported packages?

[SolarLune]

Hey, there - I'm trying to use Scriggo to build and run a Go module. The main.go imports a package in a subdirectory, but I want to substitute the declarations of that imported package prior to building - I think this isn't working currently.

For example, in the below test code, it should load a directory (subDir) that has a go.mod and main.go in its root (under the scripts directory), and then substitute the object Definitions defined in scripts/interop with the map in baseTestMain.go. Instead, nothing happens and no error is printed, which makes me think scriggo.Build() is creating a new, blank package instead of using the package I'm defining below.

assets/scripts/go.mod

module scripts

go 1.25.0

assets/scripts/main.go

package main

import "scripts/interop"

func main() {
	println("Run?")

	interop.Definitions["Test"] = 100

}

baseTestMain.go

	t := map[string]int{}

    // packages is defined earlier, has `fmt` imported

	packages := native.Packages{
		"scripts/interop": native.Package{
			Name: "interop",
			Declarations: native.Declarations{
				"Definitions":          &t,
			},
		},
	}

     // subDir here is a FS that has a root at `assets/scripts`
	prog, err := scriggo.Build(subDir, &scriggo.BuildOptions{
		Packages: packages,
	})

	err = prog.Run(&scriggo.RunOptions{})

	fmt.Println(t) // Should print map["Test": 100], instead just prints map[] 

Can someone confirm if I have the right concept on how this should work with modules?

EDIT: For clarity on what I'm asking and why, I'm making a game in Go and trying to see if I can use Scriggo as a scripting layer. I've tried this before, but it's been awhile. I'd like the user to be able to mod the game, so I'd like the game to have scripts run from assets/scripts. A file at assets/scripts/interop/interop.go would be essentially a connective layer that provides code completion, with the scriggo.Build function substituting key elements from that interop layer with things it can read from / write to, the "real" package.

[zapateo]

Hi @SolarLune! I tried to reproduce the problem you described, but I can't seem to get the same behavior. The output I get is exactly this:

Run?
map[Test:100]

And this seems correct, so I probably reproduced a different scenario than the one you tested. These below are the files I reproduced. Maybe together we can figure out what it is and reproduce the same situation that shows the behaviour you described.

go.mod

module test

go 1.26.1

require github.com/open2b/scriggo v0.61.0

baseTestMain.go

package main

import (
	"embed"
	"fmt"
	"io/fs"

	_ "embed"

	"github.com/open2b/scriggo"
	"github.com/open2b/scriggo/native"
)

//go:embed assets/scripts/*.go
var subDir embed.FS

func main() {

	subDir, err := fs.Sub(subDir, "assets/scripts")
	if err != nil {
		panic(err)
	}

	t := map[string]int{}

	packages := native.Packages{
		"scripts/interop": native.Package{
			Name: "interop",
			Declarations: native.Declarations{
				"Definitions": &t,
			},
		},
	}

	// subDir here is a FS that has a root at `assets/scripts`
	prog, err := scriggo.Build(subDir, &scriggo.BuildOptions{
		Packages: packages,
	})
	if err != nil {
		panic(err)
	}

	err = prog.Run(&scriggo.RunOptions{})
	if err != nil {
		panic(err)
	}

	fmt.Println(t) // prints "map[Test:100]"

}

assets/scripts/main.go

package main

import "scripts/interop"

func main() {
	println("Run?")

	interop.Definitions["Test"] = 100

}

In general, this is the file structure:

.
├── assets
│   └── scripts
│       ├── -go.mod
│       └── main.go
├── baseTestMain.go
├── go.mod
└── go.sum

(Note that I had to call go.mod -go.mod to avoid the Go error baseTestMain.go:14:12: pattern assets/scripts/*.go: cannot embed file assets/scripts/main.go: in different module).

Then doing:

go run baseTestMain.go

I get, as I indicated above:

Run?
map[Test:100]

Could you tell me how this test is different from your case?

[SolarLune]

Sure, thank you!

Hmm, strange, OK. I wasn't sure if this use-case was supported or not, but if it's supposed to be, then I guess there's something up. I'm able to reproduce it here with a simple test case:

scriggoReplacePackagesTest.zip

And in text form:

main.go

package main

import (
	"os"

	"github.com/open2b/scriggo"
	"github.com/open2b/scriggo/native"
)

func main() {

	opt := &scriggo.BuildOptions{
		Packages: native.Packages{
			"exampletest/sub": native.Package{
				Name: "sub",
				Declarations: native.Declarations{
					"Value": 7747, // This should overwrite exampletest.sub.Value, right?
				},
			},
		},
	}

	prog, err := scriggo.Build(os.DirFS("exampletest"), opt)

	if err != nil {
		panic(err)
	}

	err = prog.Run(&scriggo.RunOptions{}) // Doesn't print 7747, just prints 0

	if err != nil {
		panic(err)
	}

}

exampletest/go.mod

module exampletest

go 1.25.0

exampletest/main.go

package main

import "exampletest/sub"

func main() {
	println("hi, printing the value from sub:", sub.Value)
}

exampletest/sub/sub.go

package sub

var Value = 0

In the above test case, the value printed is just 0, rather than 7747 as replaced in the BuildOptions structure. It works if I change exampletest/main.go to import a package that doesn't exist (e.g. import "somethingweird/sub" and then declare that non-existent package as a native.Package in main.go), but not if the package path already does exist and I'm declaring it and overwriting its Declarations first.

[SolarLune]

Whoops, my mistake - the bug is still there, but in the above comment I was replacing the package "exampletests/sub" when it should be "exampletest/sub". Updated the code in the previous post (the zip test case is fine).

[zapateo]

Hi @SolarLune! Scriggo behaves as follows: when importing a path which refers to the inside of the module (in your case, "exampletest/sub", since the module is called "exampletest"), then only the Go source file is considered and the native package is ignored entirely.

We've opened an issue to ensure a clear error is returned in these cases.

Considering this, returning to your problem, the solution you propose doesn't seem feasible, and you need to find another solution. In case, if you want to provide more details about your specific situation, we could perhaps explore alternative options.