pathing

[whyrusleeping]

Alright, We need to make a decision on what paths should look like so I can move forward without having to worry about going back and rewriting everything.

currently, installing packages locally goes into vendor/gx/<hash>. Previously it was just vendor/<hash>
Globally installed packages get installed under $GLOBAL_ROOT/gx/<hash>.

@jbenet has suggested gx/ipfs/<hash> for protocol nesting.

Since the global root will be language dependent anyways ($GOPATH/src for go). We should probably do something similar for the local path, and default to something like gx/ipfs/<hash>. That way go packages can still specify to install under vendor/gx/ipfs/<hash>. Alternatively (go specific thing ahead), we can skip the vendor experiment thing altogether, and just have the paths be like how godep does them. (the go vendor experiment really did us fewer favors that I would have liked)

cc @noffle @diasdavid

[rht]

So if I fetch the package through ipfs, I will be stuck at updating it through ipfs namespace, and can't be through gx update https/github.com/whyrusleeping/gx or gx update ssh/git@github.com/whyrusleeping/gx or gx update ipns/<hash>?

[jbenet]

@whyrusleeping

• I think gx/ipfs/<hash> is important to not preclude other content-addressed protocols, or the evolvability of gx and ipfs both.
• But my wishes go to ipfs/<hash> as it specifies transport protocol but does not preclude other pkg management systems to reuse that pkg/transport (eg ipget alone). I think people would be hard pressed to like paths with the pkg mgr in it -- supposed you had to move everything under a global godeps/... or gb/... -- but would be ok with a protocol http/github.com and ipfs/<hash> in light of protocols-other-than-http.
• (aside, i would guess the reason http doesn't today prefix github.com is that http:// is a problem, and they resolved to only support one method per domain (http) or some adaptive heuristic).

Would love to hear what others have to say.

@rht i think you can always manually move it into place

[rht]

i think you can always manually move it into place

In git I just need to replace the remote url (when the port for a protocol got blocked by local isp), then replace back when done.

[rht]

(aside, i would guess the reason http doesn't today prefix github.com is that http:// is a problem, and they resolved to only support one method per domain (http) or some adaptive heuristic).

The godoc does not particularly state the reason.
Except that perhaps common hosts may have shorter import path.

For custom source, instead of transport protocol, it is the vcs name that is preferred to be specified, or otherwise guessed through the html meta tag.
While "each transport protocol is tried in turn for downloading".

[rht]

i.e. I vote for multiple transport protocols, one namespace.

That said, for content-addressed paths, which are already used currently, +1 for protocol prefix (gx/ipfs/hash instead of gx/hash).

[whyrusleeping]

a packages reference will always remain static, gx does not allow a 'mutable' package reference. You can however choose to update your current ref from a mutable source (See repos).

[jbenet]

ipfs is not the only immutable/merkle protocol. And we might work on others
in the future, who knows.
On Tue, Nov 24, 2015 at 19:01 Jeromy Johnson notifications@github.com
wrote:

a packages reference will always remain static, gx does not allow a
'mutable' package reference. You can however choose to update your current
ref from a mutable source (See repos).

—
Reply to this email directly or view it on GitHub
#21 (comment).

[whyrusleeping]

@jbenet yeah, i was addressing the http aspect @rht brought up.

[whyrusleeping]

@jbenet @rht @noffle @diasdavid does gx/ipfs/<hash> sound good to everybody?

[daviddias]

It sounds good to me :)

[hackergrrl]

I'm reluctantly on board with gx/ipfs/<hash>.

My hesitation was because I like npm's "single namespace" approach so gosh-darned much. The paths are very human friendly. I like that the simple node_modules/<pkg> path that is agnostic to transport and retrieval source, instead opting to let users specify both in package.json. There you could have "foo": "^1.3.0" to indicate "I want to use npm as a repo" (much like gx's repo notion), or just write "foo": "git://github.com/noffle/foo.git" to pull from elsewhere. This expands nicely to support any transport users would like, and also has the nice property of not tying the FS location of the package (node_modules/foo) to its origin.

We could totally implement this approach for gx, with one caveat: conflicts can happen if the package's plain name is used. (Though this can also happen with npm if you stray outside of npm's central repo.) @jbenet's approach of using the origin transport address gives uniqueness, which is a desirable property. Perhaps moreso than human friendliness in this case.

[whyrusleeping]

@noffle, i was thinking of being able to specify package short-names (the links that we were using earlier) to refer to package names. You can also refer to a package by its short name if it exists in one of your configured repos, either by X or by repo/X, it will fetch the appropriate version and write the hash down in the dependency map.

[hackergrrl]

So: use @jbenet's pathing model, but offer some aliasing facilities on packages? I think that's reasonable.

[whyrusleeping]

yep! I started working on this yesterday but ran into an old go-ipfs bug that i'm finally going to fix

[whyrusleeping]

we've decided on "gx/ipfs/<hash>/name". closing