Semantically versioned imports make it difficult to use golang-migrate.

[vlymar]

Is your feature request related to a problem? Please describe.
We use golang-migrate/migrate two ways:

1. as a CLI utility for manually applying migrations in prod environments
2. as a library for automatically applying migrations in test/CI environments.

For use case (1), the shift to go modules works for us. Our migrations repo is very simple and self contained. If all we needed was the CLI functionality we could easily switch to go modules.

For use case (2), the shift to go modules is a major issue. We import our migrations repo into a large production application with many existing dependencies. We know go modules is the future and are certainly investigating it, but we don't have the luxury of switching packaging tools overnight, particularly to an experimental work in progress system that won't be finalized until Go 1.13.

Until now we had pinned migrate to v3.5.4. We have been dealing with sporadic CI failures that I believe would be fixed by #150, but it now looks like we won't be able to bring in that fix without switching from govendor to go modules in our main application.

I noticed that my use case is not covered in the "Three Transitional Examples" in https://github.com/golang/go/wiki/Modules#semantic-import-versioning. As far as I can tell there is no reasonable way to consume a package that has gone all-in on go modules and is at v2+, from a project using one of old standard package managers (govendor, dep).

Describe the solution you'd like
Consider the possibility that it is too soon to go all-in on go modules. At least some other major Go projects have delayed this (e.g. elastic - #103 (comment)).

If not this, would it be possible to expand the category of what gets backported to v3? Alternatively, would you be open to me opening a PR that backports just the fix from #150 into v3?

I am admittedly somewhat new to Go and could very well be missing an obvious solution or workaround here. If someone knows of one, please let me know :).

Describe alternatives you've considered

• forking golang-migrate/migrate and getting rid of semantically versioned import paths
• using the approach outlined in adding /v3/ to urls is a breaking change when building. #103 (comment) (locally adding the v2 directory and importing from there). this is unsustainable.
• using an alternative to golang-migrate/migrate
• accelerating our migration to go modules

Additional context
FWIW, it looks like dep is working on some sort of support for semantically versioned imports, but unfortunately our largest application uses govendor and I couldn't find any comparable progress there.

Thank you for your work on this great tool <3

[dhui]

Can you describe the CI failures you're seeing in more detail?

What version of Go are you running?
migrate (v4.2.2 and master) runs fine on Go 1.10.7 using dep.

[vlymar]

Can you describe the CI failures you're seeing in more detail?

We're intermittently seeing the same failure described in #55:

Error applying coderefs migrations: pq: duplicate key value violates unique constraint "pg_type_typname_nsp_index" in line 0: CREATE TABLE "schema_migrations" (version bigint not null primary key, dirty boolean not null)

What version of Go are you running?

1.11.1

migrate (v4.2.2 and master) runs fine on Go 1.10.7 using dep

I think what you're describing is that migrate is able to install its own dependencies via dep. What I'm describing is that a project using dep cannot install migrate as a dependency. This is what issues like #123 (and this one) are referring to.

[dhui]

I think what you're describing is that migrate is able to install its own dependencies via dep. What I'm describing is that a project using dep cannot install migrate as a dependency.

Thanks for the clarification!

I'm hesitant to make exceptions for back-porting non-security related bug fixes to migrate v3. Different people/teams will want different patches back-ported and acquiescing to such requests will make maintenance more difficult and burdensome.

Since you're already running Go 1.11.x, it may be easiest to migrate to modules. go mod init does a pretty good job of converting from other package managers. Since you already have CI in place, if your test coverage is good, switching to use modules should be straightforward.
The other alternative you described that would be low effort would be to use your own fork of migrate v3 until you're ready to use Go modules. Since migrate v3 will only receive security fixes, maintaining the fork should be pretty easy. If you decide to fork, please advertise the fork in this issue so others who encounter the same problem will have a simple drop-in solution.