0

I have a project outside of $GOPATH and I want to use go mod. However, when I copy the code of from a project in $GOPATH and run

$ GO111MODULE=on go mod init github.com/jgoc/modtest
$ GO111MODULE=on go run main.go

I get an error.

go version go1.12.5 windows/amd64

package main

import (
    "github.com/hajimehoshi/ebiten"
    "github.com/hajimehoshi/ebiten/vector"
)

build command-line-arguments: cannot load github.com/hajimehoshi/ebiten/vector: cannot find module providing package github.com/hajimehoshi/ebiten/vector

Example: https://github.com/jgoc/modtest

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
Jess
  • 124
  • 1
  • 3
  • 6
  • 1
    The env var is called `GO111MODULE` ! – Volker Aug 08 '19 at 05:48
  • I edited and redo, I still get the error – Jess Aug 08 '19 at 06:06
  • 1
    Once more: The correct spelling of the relevant environment variable is: `GO111MODULE` , that is `GO111` because it was intruduced in Go 1.11 and controles modules, not. GO111MODULE not GOMODULE111 !! – Volker Aug 08 '19 at 07:08
  • 1
    Hard to offer any advice with fake imports. Please edit your question with the actual code you're having trouble with and the actual error you receive. – Adrian Aug 08 '19 at 14:10
  • Side note: based on the comment of "I have a project outside of $GOPATH and I want to use go mod", I suspect the spelling of the environment variable might have been a red herring, though good to fix. The default value is 'auto', which means you will be in module-mode outside of GOPATH if you run 'go mod init' or are otherwise in a directory outside of GOPATH with a 'go.mod' file present. This FAQ on the modules wiki has the details: [When do I get old behavior vs. new module-based behavior?](https://github.com/golang/go/wiki/Modules#when-do-i-get-old-behavior-vs-new-module-based-behavior) – thepudds Aug 08 '19 at 23:57
  • FWIW, the advice to supply actual import paths was good and import advice here -- this question was originally written as a general question, but it turns out it was actually a very specific to a specific open source dependency. – thepudds Aug 09 '19 at 13:50

1 Answers1

2

Based on the recent edits to supply actual package names, it sounds like you need to use a version of your github.com/hajimehoshi/ebiten dependency that has a vector package.

The latest version of github.com/hajimehoshi/ebiten with a valid semver release tag is https://github.com/hajimehoshi/ebiten/tree/v1.9.3. That version does not appear to have a vector package.

The @master version does have a vector package. @v1.10.0-alpha does not have a vector package. Maybe start with @master and at least see if you can compile?

This worked for me:

go get -d github.com/hajimehoshi/ebiten/vector@master

For more details, please read the How to Upgrade and Downgrade Dependencies section of the modules wiki.

Also, what is the actual name of your module? And what are the actual import paths you are using to import the code that lives in that module?

You wrote:

go mod init Desktop/modtest

Normally, the name of a module (also known as the "module path") should start with a hostname like github.com, and most often a repo, such as:

go mod init github.com/my/repo.

You then import packages in your .go code using import paths that start with that full module path that you passed to go mod init, such as:

import "github.com/my/repo/pkg1".

Using your example, it would be:

go mod init github.com/<author>/<package>

And the imports would be:

import (
    "github.com/<author>/<package>"
    "github.com/<author>/<package>/<sub-package>"
)

If your module path does not agree with your import paths, you can get errors similar to what you are seeing. (Your "module path" is what you pass as the argument to go mod init, and then you can see it on the module line in your go.mod file).

Please see this answer for some more context and a few more details.

thepudds
  • 4,787
  • 3
  • 20
  • 37
  • based on the link, my understanding, my dependency is supposed to be a repository (having go.mod per sub package), and the sub-package doesn't have a go.mod – Jess Aug 09 '19 at 00:46
  • also the package from my project using `$GOPATH`(v1.10.0-alpha) is using a different version than in my go.mod(v1.9.3), which the go.mod version does not have the package. – Jess Aug 09 '19 at 00:57
  • I am not quite following what you are trying to do, but the module name in the example you just added at https://github.com/jgoc/modtest does not agree with the repository name. If the repo is `github.com/jgoc/modtest`, then the module name on the `module` line of your `go.mod` file should be `module github.com/jgoc/modtest` – thepudds Aug 09 '19 at 05:33
  • 1
    Also, the latest version of `github.com/hajimehoshi/ebiten` with a valid semver tag is https://github.com/hajimehoshi/ebiten/tree/v1.9.3. That version does not appear to have a `github.com/hajimehoshi/ebiten/vector`. If you want a specific version, you should `go get` it. For example, the current commit on `master` appears to have a `vector` package. In particular, this works for me: `go get -d github.com/hajimehoshi/ebiten/vector@master`. Also, it is worth reading [this FAQ](https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies) on getting specific versions. – thepudds Aug 09 '19 at 05:44
  • Also, I am not sure what version you are trying to use, but the `v1.10.0-alpha` version you mentioned does not appear to have a `vector` package either: https://github.com/hajimehoshi/ebiten/tree/v1.10.0-alpha – thepudds Aug 09 '19 at 05:47
  • I just want to use the `vector` package – Jess Aug 09 '19 at 05:51
  • 1
    OK. You need to use a version of your dependency that has a `vector` package. The `@master` version does have a `vector` package. `@v1.10.0-alpha` does not have a `vector` package. `@v1.9.3` does not have a `vector` package either. Maybe start with `@master` and at least see if you can compile? As mentioned above, this worked for me: `go get -d github.com/hajimehoshi/ebiten/vector@master` – thepudds Aug 09 '19 at 05:58
  • Edited answer to reflect the new information about the actual package names of interest. – thepudds Aug 09 '19 at 06:08