Dep: Idea: Allow creation of aliases in Manifest.json

[davidbarsky]

First of, thank you so much for your hard work on this project. Y'all are doing great work on this issue. Second of all, my apologies is this isn't the right place to open this issue.

My idea is to an introduce an alias keyword in manifest.json. For instance:

{
    "dependencies": {
        "github.com/pressly/chi": {
            "version": "^2.0.0",
            "alias": "chi"
        }
    }
}

This command would place the chi package under /vendor/chi instead of /vendor/github.com/pressly/chi. Therefore, packages could be imported as:

package main

import (
  "net/http"
  "chi"
)

Since golang/dep treating third-party packages as first-class citizens, I believe that import syntax should reflect this cultural change. Of course, there are many issues that I did not consider and could make this difficult. All that being said, thank you for your time and for listening to this idea!

[sdboyer]

Thanks for making the suggestion :) I quite understand the impulse for it, and have had a similar thought myself. Unfortunately, though, I don't think this would be workable. There's a few things I could point to, but one is most clearly disqualifying: conflicts. There are (at least) four classes of conflict such aliases would allow.

Let's think about how this would have to work. A manifest declares an alias, which is basically a mapping from a project root (chi) that's seen in the code, to the original, proper project root (github.com/pressly/chi). Because you're going to commit code with these aliased import paths, it's necessary that anything else depending on your project _also_ know that github.com/pressly/chi is aliased to chi; otherwise, this becomes a backdoor to duplicating projects, which is something we try very hard not to do.

For ubiquity of the aliasing to be enforced and this backdoor avoided, it means the solver would have to hoist aliases from dependent projects' manifests up globally, anywhere github.com/pressly/chi appears in the depgraph. So, if any OTHER project in the depgraph ALSO relies on github.com/pressly/chi, then there's a potential for conflict if that other project either a) specifies no alias, or b) specifies a different alias.

That's two conflict classes. The third is, if you alias to chi, and something else in your depgraph ALSO aliases to chi, but it's a totally different project (github.com/foo/bar). And the fourth - what if you alias to bytes (stdlib), or github.com/something/real? Is that OK, or is it an error to supercede something else in that way?

Import paths provide considerable canonicality of names; it's a useful property, and one we should maintain as much as possible.

Also, let's not forget that we have to construct an on-disk representation of your deps in vendor/ that will actually compile. If you were to alias github.com/pressly/chi as just chi, then that means it would have to live at vendor/chi for the imports to be picked up. Now, that project seems to have rather isolated packages, but if it has internal imports (e.g. github.com/pressly/chi imports github.com/pressly/chi/middleware), then those import paths would have to be internally rewritten in the code in vendor in order to make the package internally consistent. And we don't do import path rewriting, ever. If nothing else, it changes the text in files, which makes hashing the contents of vendor even more difficult (#121).

So, yeah - nifty idea, but I can't see it working well. It's a superset of the problems that specifying an alternate source has, but with much less benefit - whereas alternate sources let you transparently swap in e.g. a fork, or more (#174). I can't think of a problem this solves apart from typing fewer chars.

I'm going to close this as a clear signal it won't work, but again, thanks for the idea, and please don't be discouraged from posting more ideas if you have them!

[davidbarsky]

You've raised great points that in my haste I didn't consider (partially the conflicts in /vendor). Your explanation has taught me a lot about the complication model, and I'm really thankful for that ❤️.