Proposal: consider removing hash/version information from the import path

[schomatis]

I am aware I'm a couple of years behind (#21), this breaks the current API and there may be many design considerations I'm not aware of behind this decision, my main motivation for this proposal is to make gx more user-friendly to encourage its adoption outside the IPFS ecosystem.

The rationale behind this proposal is that normally when a user imports a dependency in most languages its version is something that is stipulated outside of the import reference in the source file, normally in some other installation management file (the Makefile or even package.json). The fact that it's not specified in the source file doesn't mean it isn't enforced during the build process. Normally the version is not explicit while working with a package but rather the developer has different tools to manage it (like running a version command or even git status). (I'm not even sure how much a new user who wants to adopt gx should need to be IPFS-aware.)

Navigating the source tree with hashes of 46 characters long (and this number will only grow, sha3-512 has a CID of 93 characters long) can be overwhelming for the new user (I'm speaking from my own experience), even reading the import line entails an eye effort to distinguish which is the package being imported at the end of the hash.

I'm not going to enter in the concrete technical details of what would it take to remove the hash from the path, e.g., in a global workspace there could coexist different versions of the same package and there should be a way to distinguish them (or maybe that should just not be allowed, as it normally isn't a use case right now, different projects with different dependency versions have their own workspace). My main goal here is to state the motivation as clear as possible to discuss if the change would be worth it or not.

This is by no means a critic to gx, on the contrary, I consider it to be the first concrete IPFS success story and I would like to see it adopted in a wider developer community.

[whyrusleeping]

Apologies for not taking the time to reply at length,

I'm amenable to solutions that allow developers working on the codebase to not have to deal with the hashes in the paths (see gx-go devcopy). That said, i always want the hashes in the paths for builds, thats an incredibly important aspect of the system (and has saved me countless hours of time debugging stack traces).

[schomatis]

I'll give gx-go devcopy a try then to see if it simplifies the development process.

That said, i always want the hashes in the paths for builds, thats an incredibly important aspect of the system (and has saved me countless hours of time debugging stack traces).

Yes, I definitely see the advantage of having the hash in the path during a stack trace instead of having to look inside a different file (like package.json) to see which version of a package is being used, especially if you don't have access to the environment (like someone posting a crash stack trace on an issue).

That being said, I don't think the hash adds a lot of value in itself, I'm assuming you care about the hash because you want to know the version information of the package listed, but maybe the hash could be replaced with the version tag in the import paths, which would be a shorter and human-readable string. I'm not saying that the tag should be part of the VCS, gx would still use the hash in package.json to retrieve and control packages, I'm just proposing adding abstraction layer in the middle to improve user experience.