-6

I have this script:

#!/usr/bin/env bash

set -eo pipefail

cd "$(dirname "$BASH_SOURCE")";
pth_to_make="$GOPATH/src/ores/json-logging"
mkdir -p "$pth_to_make";
rm -rf "$pth_to_make";
ln -sf "$PWD" "$pth_to_make";

however this module is not declared as a go module in go.mod...I am symlinking a different dependency into the repo to test it.

The real dependency in production is at:

"$GOPATH/src/github.com/oresoftware/json-logging"

the test path is:

"$GOPATH/src/ores/json-logging"

Now, I would just delete the real dependency path in local development, the problem is that it then just deletes the .git folder in the repo and then I end up having to download that again.

Is there some way for me to symlink over the real repo/dep folder, but not lose the git stuff? Maybe I could do:

 mv   "$GOPATH/src/github.com/oresoftware/json-logging"  "/tmp/gotemp/json-logging"
 # call the script above
 # then when I am done:
 rm -rf "$GOPATH/src/github.com/oresoftware/json-logging"
 mv "/tmp/gotemp/json-logging" "$GOPATH/src/github.com/oresoftware/json-logging"  # put it back

would that be the best way forward?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
  • 4
    Stop doing crazy stuff. Read how to Write Go Code twice. Follow it and stop fidling with file paths. Use replace directives to use local Version of dependecies. Never use symlinks. – Volker Mar 12 '20 at 06:15
  • lol ok as if go modules wasn't introduced yesterday cause it was –  Mar 12 '20 at 06:33
  • my code is close to working with the old way, but go modules seem to exist in a new location. symlinks are very useful and it's pretty dumb if symlinks aren't first class citizen in go-land. –  Mar 12 '20 at 06:34
  • 3
    Please write [How to Write Go Code](https://golang.org/doc/code.html). – mhutter Mar 12 '20 at 06:47
  • this is not how to write go code, this is how to do dep management, and local software development of a go module - I doubt there is an answer to this - if there is link to it - "read the docs" is not an answer. there is no answer without symlinks, otherwise you have to use `mv` - which is pretty much the same thing without symlinking. –  Mar 12 '20 at 07:05
  • 3
    Dependency management works via go modules. Use go modules. Using local version of go modules is done via replace directives in the go.mo file. What you try to do is known to be error prone (to put it lightly). Let me repeat for you: Do not use symlinks. Stop doing crazy stuff. Use Go modules if at all possible. If not: use a proper GOPATH setting, copying your sources there. No symlinking. – Volker Mar 12 '20 at 07:32
  • as a frickin example - symlinks *do indeed work* with go build - however, the IDEs, such as jetbrains, do not support symlinks in terms of resolving deps. my guess is that symlinks are not "officially" supported by Golang, so the IDE makers are hesitant to include support for them. this is the level of BS right now, and you know it. –  Mar 12 '20 at 07:44
  • the problem, as it's not clear from OP, is that developing a module locally means you have to take a codebase that normally references a dep in the cloud, and reference the local dep, so the path in the codebase "github.com/whatever" needs to point to a local dependency. Is it obvious now? –  Mar 12 '20 at 07:45
  • 1
    Question is a little unclear but presuming you want to use your "test dependency" rather than your "productive dependency" if you are using go modules you can use the replace directive, which is covered more [here](https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive). That way it will reference your local module instead of wherever it was originally stored. From what I can gather there is no requirement to symlink to solve your issue, either that or the question really needs clarifying. – Mikey Mar 12 '20 at 07:54
  • 3
    "Would that be the best way forward?" -- Stop fighting the tools. – Jonathan Hall Mar 12 '20 at 08:03
  • sometimes the tools are imperfect - case in point as I already mentioned - go modules was a long time coming and is pretty new –  Mar 12 '20 at 08:26
  • 3
    You can insist on doing things _your_ way and _only_ _your_ way and blame the tools or you can accept what experienced people know about the subject and follow their advice. It is basically up to you. You seem not to be willing to follow recommended practices because you don't like them, your old way of working was different and you are not willing to understand the ideas behind these practices. So why even ask here on SO? – Volker Mar 12 '20 at 09:15

1 Answers1

2

So to expand on my comment it sounds like what you are after is the replace directive which you can read more about here. But i've outlined a brief example below;

If we imagine the directory structure:

├── replace-directive
│   ├── go.mod
│   └── replace.go
├── sandbox
│   ├── go.mod
│   └── main.go

The replace-directive is a go module with the go.mod file containing:

module example.com/replacedirective

go 1.14

Sandbox is where we want to use this local dependency version rather than grabbing the version from example.com. So in our sandbox go.mod file we have the replace directive as follows;

module example/sandbox

require (
  example.com/replacedirective v0.0.0  // This would be your reference to your production dependency
)

replace example.com/replacedirective => ../replace-directive // This is your local dependency

go 1.14

So now when you reference the module in your code it will use your local dependency instead. No symlinks required.

Mikey
  • 2,606
  • 1
  • 12
  • 20
  • and how does the replace directive work when someone else uses your module as a depedency? makes no sense. how would it know if you were on your machine or some end users machine? –  Mar 12 '20 at 08:28
  • 1
    So you want a shareable forked version of a dependency to be used by all those who utilise your code? If you set up symlinks on your machine they would not be set up on another machine - if that's what you're after and you only want it to be present on your machine for testing then don't commit the changed `go.mod` file (which I wouldn't recommend doing in most circumstances). That way other people will default back to the original module stored at `example.com`. – Mikey Mar 12 '20 at 08:41
  • I don't understand. the `go.mod` file in my repo is going to be used by other modules when they depend on mine. if the replace directive is in my `go.mod` file, then won't that mess up people on any machine but mine? –  Mar 12 '20 at 23:35
  • It's extremely unclear what you're after. From what I can gather you have a project that has a dependency on a package. You want to **temporarily** point that package to one of your local packages for _testing_ purposes. Is this something you want your team to be doing as well? In which case they would need access to your local package regardless and at which point you can just share the go.mod. Think you need to update your question to be more specific with what your expections are for a) your machine b) other people's machines c) reason behind using a local dependency over the remote – Mikey Mar 13 '20 at 09:10