Open dignifiedquire opened 5 years ago
What's the output of gx-go link
?
When Gx runs the post-install
hook on a package directory it "marks" it with that file to avoid rerunning it later (I'm not sure the rationale behind it, I mean, in which Gx work flow that hook is called multiple times and why is that avoided, if for performance reasons or because the hook operation is not meant to be idempotent).
(@Stebalien This is related to the https://github.com/whyrusleeping/gx-go/pull/51#issuecomment-417018500 in gx-go link
where re-linking has no effect because this hook is not rerun).
@schomatis that's assuming that the package was linked, right?
that's assuming that the package was linked, right?
Not sure I follow, the hook is independent of the link command, I mean, gx-go link
is just one of the commands that calls gx-go hook post-install
(e.g., so does gx install
), so I don't think there's any assumption about that.
gx won't usually run the post-install hook in a normal repo; it should only do that when it installs packages in $GOPATH/src/gx/ipfs/...
. The issue here is that gx is, for some reason, doing exactly that (dropping a post-install
file in the github repo) when used with gx-workspace.
gx won't usually run the post-install hook in a normal repo;
The issue here is that gx is, for some reason, doing exactly that (dropping a post-install file in the github repo)
Ok, now I understand the original question. Yes, the hook is run in $GOPATH/src/gx/ipfs/...
but that path is linked to a github path so the hook is effectively being run in a git-cloned repo. I'm not sure if I would consider this is a bug (it seems to me more like we don't clarify well enough what does our link API do).
(By the way, this is a nice example of why I would like to invest some time defining a clear path terminology, to avoid terms like "normal" or having to specify the entire $GOPATH/src/gx/ipfs/...
to mean that I'm referring to that kind of paths instead of the "normal" ones.)
I'm not sure if I would consider this is a bug (it seems to me more like we don't clarify well enough what does our link API do).
"that's assuming that the package was linked, right?"
If the package isn't linked, then this is a bug. And really, gx-workspace shouldn't care so this is probably a bug.
What's the output of gx-go link?
In which repo, the one with the file, or the one I used gx-workspace from?
Some details
> go-merkledag (master) ✗ ls .gx
lastpubver post-install
> go-merkledag (master) ✗ gx-go link
QmRiQCJZ91B7VNmLvA6sxzDuBJGSojS3uXHHVuNr3iueNZ /Users/dignifiedquire/.go/src/github.com/ipfs/go-merkledag
> go-merkledag (master) ✗ cat .gx/post-install
> go-merkledag (master) ✗ ls -lh .gx
total 8
-rw-r--r-- 1 dignifiedquire staff 55B Aug 30 14:08 lastpubver
-rw-r--r-- 1 dignifiedquire staff 0B Aug 30 14:13 post-install
Yeah, you've linked a dependency. Basically, this means that whenever you "install" that dependency, it'll rewrite it and add the post-install file.
When using gx-workspace
, you should either:
@schomatis is right, this is a documentation issue.
I had not linked this before using gx-workspace, so this sounds more like an issue with the interaction between the two.
I also still don’t understand how not cleaning up empty files is not a bug in any state. On 31. Aug 2018, 19:34 +0200, Steven Allen notifications@github.com, wrote:
@schomatis is right, this is a documentation issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
I had not linked this before using gx-workspace, so this sounds more like an issue with the interaction between the two.
But you had run gx-go link
on go-merkledag sometime in the past, right (the answer is almost certainly yes). That will globally symlink gx/ipfs/.../go-merkledag
to github.com/ipfs/go-merkledag
.
I also still don’t understand how not cleaning up empty files is not a bug in any state.
These are the marker-files gx leaves behind once it installs a package in gx/ipfs/...
. They tell gx that the rewrite completed successfully and the package has been properly installed (we could probably also do it by first putting the package in a temporary directory and then moving it but that's not how gx currently works).
Sometimes an empty
.gx/post-install
file is generated after running through an update from gx-workspace. I haven't found a pattern yet, as to when or why.