v2.0.0: main.go imports v1 module path, causing a dual-version transitive dep

[veggiemonk]

The v2.0.0 tag (commit f18280f on the v2 branch) ships a go.mod that declares the module as github.com/campoy/embedmd/v2, but main.go still imports the v1 library path:

// main.go on the v2 branch
import (
    ...
    "github.com/campoy/embedmd/embedmd"          // ← v1 path
    "github.com/pmezard/go-difflib/difflib"
)

The v2 module also ships its own copy of the library at github.com/campoy/embedmd/v2/embedmd (same package embedmd, same files) — but main.go never references it.

Effect

Any consumer that adds embedmd v2 as a Go tool (e.g. go.mod tool directive github.com/campoy/embedmd/v2) ends up pulling both module versions into their dependency graph:

require (
    github.com/campoy/embedmd v1.0.0       // indirect — for main.go's `embedmd` import
    github.com/campoy/embedmd/v2 v2.0.0    // indirect — for `package main`
)

go mod tidy cannot eliminate either one. The v1 module is only needed to satisfy a misrouted import inside the v2 binary; functionally, the v2 binary executes v1's library code, not v2's own copy.

Reproduce

mkdir /tmp/probe && cd /tmp/probe
go mod init probe
cat >> go.mod <<'GOMOD'

tool github.com/campoy/embedmd/v2
GOMOD
go mod tidy
go tool embedmd -h    # works, but…
grep embedmd go.mod   # …both v1 and v2 are in require.

Repo state

• master branch: still on v1 (module github.com/campoy/embedmd), actively maintained
• v2 branch: abandoned since 2018-11-27, carries the broken tag
• No v2.0.1 published

Suggested resolutions

There are a few options; happy to send a PR for whichever you prefer:

1. Fix and retag. Change v2/main.go's import from github.com/campoy/embedmd/embedmd to github.com/campoy/embedmd/v2/embedmd, then cut v2.0.1. Existing v2.0.0 consumers update once and the dual-version dep disappears.

2. Retract v2.0.0. Add retract v2.0.0 to master's go.mod (or to a fresh v2 release) so the Go module proxy warns consumers off. Forces v2 users onto v1, which is what the binary already runs anyway.

3. Deprecate v2 entirely. Mark the v2 branch deprecated, document v1 as the supported line.

Option 1 is the smallest change and unblocks v2 consumers. Option 2 is the most honest about the current state (v2 has no real code differences from v1 in what actually executes). Let me know which direction you'd like and I'll send the PR.