Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question: support for projects without a go.mod? #3

Closed
mpl opened this issue Apr 29, 2019 · 4 comments
Closed

question: support for projects without a go.mod? #3

mpl opened this issue Apr 29, 2019 · 4 comments

Comments

@mpl
Copy link

mpl commented Apr 29, 2019

As per the README: "where mod1 and mod2 are module directories with a go.mod file."
Does this mean that L won't ever support projects without a go.mod and/or with GO111MODULE=off ?
If yes, is that due to a limitation of gopls?

P.S: I've just had a quick try and already found what I think are two obvious problems, but not sure I should open issues as you probably are already aware of them:

  1. apparently the argument to -workspaces needs to be an absolute path. I've tried with a (valid) relative path, and things didn't seem to work.
  2. 'L def' seems to result in an address like /some/path:line:column , which does not seem to open. If I remove the :column , it works. Or maybe I'm missing some plumb rules that are not by default in p9p acme?

Let me know if you want me to open issues for the above.

@fhs
Copy link
Collaborator

fhs commented Apr 29, 2019

As per the README: "where mod1 and mod2 are module directories with a go.mod file."
Does this mean that L won't ever support projects without a go.mod and/or with GO111MODULE=off ?
If yes, is that due to a limitation of gopls?

Yes, it's a limitation of gopls. You can always use go-langserver for non-module projects, but I don't know how much longer it'll be maintained. Everyone is moving to modules because module mode will be turned on by default in Go 1.13, and GOPATH mode will be deprecated.

P.S: I've just had a quick try and already found what I think are two obvious problems, but not sure I should open issues as you probably are already aware of them:

  1. apparently the argument to -workspaces needs to be an absolute path. I've tried with a (valid) relative path, and things didn't seem to work.
  2. 'L def' seems to result in an address like /some/path:line:column , which does not seem to open. If I remove the :column , it works. Or maybe I'm missing some plumb rules that are not by default in p9p acme?

Let me know if you want me to open issues for the above.

Don't worry -- I'll have these fixed by end of the day.

@mpl
Copy link
Author

mpl commented Apr 29, 2019

Understood, thanks.

@mpl mpl closed this as completed Apr 29, 2019
fhs added a commit that referenced this issue Apr 29, 2019
Pass address directly as an attribute, so we don't rely on the standard
plumbing rules to be loaded. This problematic especially since reloading
rules is broken: 9fans/plan9port#256

Update #3
@fhs
Copy link
Collaborator

fhs commented Apr 29, 2019

I fixed those two issues.

The plumbing issue may have been caused by how reloading plumber rules is broken: 9fans/plan9port#256. In any case, we don't depend on those rules anymore.

@mpl
Copy link
Author

mpl commented Apr 30, 2019

nice

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants