search

whyrusleeping / gx

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

`gx install` shouldn't copy files to a new directory #152

Open fiatjaf opened 6 years ago

fiatjaf commented 6 years ago

I don't know exactly how does this work on IPFS, but I imagined something like a ipfs mount would not use more disk space than IPFS is already using in its base datastore, am I right?

So if gx somehow just used ipfs mount to serve the files of the packages that are already downloaded and already sitting in the ipfs default datastore, that would help a lot the people who are suffering with lack of disk space like me.

Actually, I thought gx would be a killer package manager because of that -- specially if used with node modules, that otherwise are duplicated millions of times (if you have many projects in many folders).

In case of Go, perhaps gx could symlink from $GOPATH/src/gx/ipfs/<hash> to /ipfs/<hash>. Why not?

whyrusleeping commented 6 years ago

@fiatjaf I definitely agree. The only reason (aside from fuse being... picky) we cant do that right now is because of subpackages (at least, in go). In order for github.com/ipfs/mygxpackage/foo to import github.com/ipfs/mygxpackage/bar, it needs to reference the hash of the package, which it cant know until its publish. Which means that as a post install step, we do some import path modifications of installed packages. This prevents us from serving the files directly out of ipfs.

fiatjaf commented 6 years ago

You mean github.com/ipfs/mygxpackage should be published before it can reference its own paths?

Why can't github.com/ipfs/mygxpackage/bar and github.com/ipfs/mygxpackage/foo be published independently? Then we could add /ipfs to the $GOPATH and refer to hashes directly (apparently multiple paths are supported, although I didn't know that until a minute ago).

whyrusleeping commented 6 years ago

Why can't github.com/ipfs/mygxpackage/bar and github.com/ipfs/mygxpackage/foo be published independently?

That is the right solution, but its really inconvenient for a lot of packages.

djdv commented 6 years ago

I might be misunderstanding the issue here but

it needs to reference the hash of the package, which it cant know until its publish Which means that as a post install step, we do some import path modifications of installed packages. This prevents us from serving the files directly out of ipfs.

Would the MFS help in anyway with this? gx could stage necessary modifications and stat the hashes it needs, for use as mounted paths. i.e. {/ipfs}/mfs/staging/dep -> /ipfs/Qm..../dep

This would accrue some garbage but presumably less than a full copy and get around the fact that mounted IPFS is immutable.