How do you test an unpublished module?

[Peter Kleiweg]

Suppose I am writing a package that is in its own module, and I want

to test it. Not with unit tests, but with a larger program that uses

other non-standard packages as well.

Before modules, I would develop the package in ~/go/src, write the

test program somewhere else, and import the package. This doesn't work

with modules.

What does work is move the test program into a subdirectory of the

package, add that directory to .gitignore . This works, as long as the

test program doesn't need any non-standard packages that the package I

am writing needs.

When the test program needs more non-standard packages, I need to add

these to go.mod of the package I am developing, even though that

package itself doesn't need it.

When I give the directory with the test program its own go.mod then it

can't use the files in the parent directory as the imported package.

I turned it the other way around. I put the package I am writing in a

subdirectory of the test program. That works, as long as that subdirectory

doesn't have its own go.mod .

So, in one setup, I end up with a package with a go.mod with too many

dependencies. An in the other I end up with a package without a go.mod .

How do I get this right?

Is there a way to tell go.mod that it should use local files instead

of a repository, just for the development phase?

[Wojciech S. Czarnecki]

Dnia 2021-02-20, o godz. 04:10:38
Peter Kleiweg <pkle...@xs4all.nl> napisał(a):

> Suppose I am writing a package that is in its own module, and I want
> to test it. Not with unit tests, but with a larger program that uses
> other non-standard packages as well.

[...]

> How do I get this right?
>
> Is there a way to tell go.mod that it should use local files instead
> of a repository, just for the development phase?

No. You can not replace *files*. You can use workaround with
briliant hack of https://github.com/rogpeppe/gohack

Other hack is to have two or more modules you want to tinker with
vendored simultaneously to "all interested parties". This can be achieved
in Linux as shared mount, on other OS it need to be exact copy.
It is tedious but works.

Look at https://github.com/golang/go/issues/27542#issue-357818109 and
https://github.com/golang/go/issues/37755 to get hints about other hacks
people conceived to be able to work on interdependent code.

Hope this helps,

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Peter Kleiweg]

Reading https://github.com/rogpeppe/gohack en trying some things, I found that 

you *can* tell go.mod that it should use local files instead of a repository.

I have a test program outside my `~/go` tree with a `go.mod` like this:

```

module peter.nl/tester

go 1.16

replace github.com/pebbe/package => /home/peter/go/src/github.com/pebbe/package

```

Then I run this:

```

go get github.com/pebbe/package

```

Now I can build and run the test program, and when I change anything locally in 

`/home/peter/go/src/github.com/pebbe/package` and build the test program again,

it reflects the changes made in the package. This is exactly what I need.

Op zaterdag 20 februari 2021 om 13:45:15 UTC+1 schreef ohir:

[Wojciech S. Czarnecki]

Dnia 2021-02-20, o godz. 07:52:26
Peter Kleiweg <pkle...@xs4all.nl> napisał(a):

> you *can* tell go.mod that it should use local files instead of a repository.

[...]
> replace github.com/pebbe/package => /home/peter/go/src/github.com/pebbe/package

In that sense, yes. You point to package directory and there are files :)

[Carla Pfaff]

The modules documentation has a section on this: "Developing and testing against unpublished module code"

https://golang.org/doc/modules/managing-dependencies#tmp_9