Comments (9)
@sahib yeah, This is a problem we've been having even before using gx.
Take a look at this gist: https://gist.github.com/whyrusleeping/a297dc2ae4b3f54daa666fc1f04562a8
Its the same exact problem, and a failing in how go works, if you were using gx for javascript, this wouldnt be an issue.
The solution i'm trying to work towards is twofold, the first is to take a better approach at how we design the interfaces we export. Some discussion of that is here multiformats/go-multiaddr#17
The second part of the solution i mention near the end of that thread is a non-breaking change to how go checks interfaces.
from gx.
The quick and dirty solution for now is to just replace the imports in your code with the gx imports from the error message.
from gx.
Sorry for blaming it on gx
then.
The quick and dirty solution for now is to just replace the imports in your code with the gx imports from the error message.
Sadly really a dirty solution that will break again when packages are updated.
I will go with that until a better solution comes the way.
I guess this can be closed then.
from gx.
@sahib this is a problem i'm very interested in solving. If you come across any good solutions, please let me know
from gx.
Apologies in advance for a big post on a closed issue. But this exact problem has us in a particular world of pain atm.
We're building on top of the wonderful, stupendous, ipfs/go-ipfs. But not using GX quite yet, this Golang/GX type conflict problem is forcing us into a tough choice:
- Convert our entire codebase to using GX and keep lock-step sync with go-ipfs imports (a costly endeavor when we're on tight timelines).
- Fork go-ipfs and re-write all imports
- (we're currently) wrapping all of the IPFS bits we need in a package & shimming relative imports via interfaces.
In all honesty none of these options are the end of the world, but as someone very excited to build upon IPFS, and who wants others to build on ipfs, I can see how this would be the point where others would be less inclined / confused about how to solve the gx/no-gx issue in a codebase.
I think the spirit of GX is fantastic, but having hashes in me imports makes for terse stack traces, which often overflows my stderr so fast I can't see initial panic messages. Of greater concern is the cognitive overhead foisted onto the developer by having hashes in the import paths. Initial internal code reviews of gx'd code always start with a five minute tangent about what gx is, and then it's 10 minutes later and I'm still grumbling about go's super-duper-specific type system. 20 minutes after that we're in a holy war about weather anything is ever "idiomatic" or not, and all I wanted to do was ask for more unit tests.
Annnnnyway, none of this is to dump on gx specifically. gx seems to have a lot to say about build reproducibility without making us vendor everything all the time, and when looking at a gx'd package.json
I'm reminded a lot of yarn lock files which use hashing techniques to solve npm nightmares. I'm wondering if it would be worth exploring a version of gx that obeys GOPATH-relative imports, but leverages package.json
as a lock file that manages the vendor
directory, with a gx test that could be included as a CI test? Some variation? Maybe gx generates symlinks in vendor
to some content-addressed backing store for deduplication? Ok, that last bit sounds bonkers.
Another option would be to explore go's new alias feature, but that's a half-baked idea at best.
I'd love to join any discussion / dev about helping GX overcome this go-specific packaging issue if you'd have me (and by no means do any of the above ideas need to be implemented). Thanks for writing super fantastic awesome code, and please let me know if I can help!
from gx.
@b5 Could you link me to your codebase? I'd love to have a case study on 'how people interact with gx'. There are a few different ways I can see moving forward, the simplest might be something along the lines of gx-go use github.com/ipfs/go-ipfs
, which could automagically set up gx import paths in the project its run in, and maybe even make them point to hashes via symlinks in some way.
On the other hand, youre importing go-ipfs directly. What modules are you using exactly? go-ipfs is comitted with gx'ed deps because we don't want people to build it with incorrect deps accidentally and encounter bugs. Thats just required for the binary (package main
), the rest of the packages are slated for removal from the main repo. All our other repos outside of go-ipfs are committed with github import paths, and you should be able to interact with them as you would any other normal go package.
from gx.
@b5 Also, Just to be clear, if youre importing go-ipfs, you don't necessarily have to use gx for all of your deps. Just the ipfs ones.
from gx.
Thanks @whyrusleeping! sorry for the delay on this, things have gotten a little nutty on my end. The codebase in question is currently closed, but will be opened up once the lawyers give us the go-ahead (hoping to release white paper on Oct. 31st, code shortly after), I'd be happy to invite you to review our codebase beforehand if you're interested, there are a few approaches in there that I'm very excited to get feedback on and see if there's anything we could work into tools the broader community could make use of.
I had a look at go-go use (I had hoped that tool would be around somewhere, but hadn't found it). In the end I bit the bullet & did the gx conversion for all IPFS related things manually, it was less painful than expected. ended up doing it manually b/c sometimes we're passing around things that exist just to satisfy interfaces, which makes room for gx / no-gx interplay.
I do now see the light on tracking directly with IPFS imports. Part of me thinks this should be filed under being mindful of our dependencies. Thanks again for the great work, and looking forward to upping our contributions to IPFS in the future!
from gx.
@b5 Thats great to hear :) Any notes you have on how we can make this all easier would be much appreciated, either in the way of docs, tooling, bugfixes or anything else that could possibly help out.
from gx.
Related Issues (20)
- gx packages should be read-only HOT 6
- Special document of how is `gx` used in `go-ipfs`
- What happens when I install `go-ipfs`? HOT 1
- Add an option to use package name and version in the import path for new developers HOT 4
- empty .gx/post-install created HOT 13
- `gx lock-install`: option to make relative links HOT 1
- install --save installs multiple times
- Gx-ify Gx HOT 1
- knownhosts missing? HOT 3
- Replacing a gx-lock vendored dep with a symlink causes `gx install` to panic HOT 10
- gx link
- v0.14.0 publish broken HOT 5
- error in go get -u github.com/whyrusleeping/gx HOT 1
- when i input 'go get -u github.com/whysleeping/gx' the item return me package unrecognized import path HOT 2
- i cannot use the command gx? HOT 1
- Can't publish; please run an ipfs node and try again HOT 7
- why "inner import" of go-ipfs package published by gx contain hash value HOT 4
- Build issues for ppc64le architecture HOT 2
- Using gx for other languages than go HOT 1
- Breaking change in dependency HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gx.