search

whyrusleeping / gx

A package management tool
MIT License
1.88k stars 110 forks source link

import hell #160

Closed jvsteiner closed 6 years ago

jvsteiner commented 6 years ago

I have been using gx for a couple of weeks now, and every so often i run into massive headaches. I have running code, I import a new package, but the gx version referred to by my use of the new package returns an object which is on a different gx version than expected by my existing code. for example:

./narc.go:260:26: cannot use dstore (type repo.Datastore) as type "gx/ipfs/QmPpegoMqhAEqjncrzArm7KVWAkCm78rqL2DPuNjhPrshg/go-datastore".Batching in argument to dht.NewDHT:
    repo.Datastore does not implement "gx/ipfs/QmPpegoMqhAEqjncrzArm7KVWAkCm78rqL2DPuNjhPrshg/go-datastore".Batching (wrong type for Batch method)
        have Batch() ("gx/ipfs/QmdHG8MAuARdGHxx4rPQASLcvhz24fzjSQq7AJRAQEorq5/go-datastore".Batch, error)
        want Batch() ("gx/ipfs/QmPpegoMqhAEqjncrzArm7KVWAkCm78rqL2DPuNjhPrshg/go-datastore".Batch, error)

How, in the general case, is a developer meant to resolve issues like this? I want to import a few packages which have differently versioned dependancies of the same package. I can see using gx deps dupes that they are there, but I don't know where in the dependency tree they exist, and have no idea what to do about it.

I would need to import or use a previous version of some package, where the constructor I call returns an object where the gx-ified type matches what my existing code expects, but I haven't a clue how to go about it. Any thought?

whyrusleeping commented 6 years ago

This is the main sticking point with full version locking. All the versions in the tree need to match. We have a (still fairly WIP) tool called gx-workspace that helps to bubble up changes to dependencies throughout the tree.

One proposal I have that would help to side-step this issue is giving packages the ability to pull all dependencies from a given registry: https://github.com/whyrusleeping/gx/issues/151 It would then be on the registry maintainers shoulders to ensure that all the packages interop with eachother properly (which is a bit easier than it sounds, and can be automated) but then any package wanting to use gx packages just needs to say "use deps from registry X" and periodically they can just update the registry reference to get new packages.

There is a lot of tooling we can build that makes all this a lot simpler. We just need to find time to go build it.

Sorry for the late reply, Thanks for trying out gx :)

jvsteiner commented 6 years ago

moving to other thread - closing here.