gopkg support

[drewwells]

This is a useful convention for locking in versions of dependencies. http://godoc.org/gopkg.in/v1/docs

I believe it doesn't work out of the box due to the app/routes/routes.go that gets generated on build.

[landaire]

I've been wanting to propose this as well. routes.go I'm guessing doesn't work because of the import path?

[pushrax]

We talked about this in #530 and decided against it at the time. Further discussion here is welcome, but if the assumptions made there were correct (notably that we would need to alter all of revel's import paths) I'm still of the opinion it's not the best way to handle dependency management.

[drewwells]

That's a good point lets take this up with the gopkg team.

On Sat, Mar 22, 2014 at 6:30 PM, Justin Li notifications@github.com
wrote:

We talked about this in #530 and decided against it at the time. Further discussion here is welcome, but if the assumptions made there were correct (notably that we would need to alter all of revel's import paths) I'm still of the opinion it's not the best way to handle dependency management.

Reply to this email directly or view it on GitHub:
#564 (comment)

[drewwells]

I sent an email explaining this problem. Here's his response:

How can revel be modified to use gopkg without having to rewrite all the
imports internally on every version?

That's a good question.

It was recently announced in a few places that gopkg.in started to
enforce the use of major versions in the import path. In other words,
Revel can still tag revisions as v0.9.1, but the import path should be
gopkg.in/revel/v0/revel (or gopkg.in/v0/revel, if you name the
organization as "go-revel"), and gopkg.in will direct go gets to the
latest version (v0.9.1, in this case).

This solves a few different issues. One of them is what you describe
above: when using a major version, you can use the exact same import
path both internally and extrenally without changing it on every
revision.

The other one is more subtle, and a lot of people don't realize is an
issue until too late:

Alice imports Revel 0.9.1 on package A
Bob imports Revel 0.9.2 on package B
Cath imports packages A and B into her app C

As a consequence, Cath's app will have two different copies of Revel,
just slightly different. With the new constrained model described,
Alice and Bob will instead import /v0/revel, and Cath will happily
take the latest revision available that is compatible with her code,
(v0.9.2, in this case).

[brendensoares]

Using a latest aka v0 version in the import path would defeat the purpose of version locking, wouldn't it? The point is to create a dependency on a specific version, right?

[drewwells]

Yes, thats what the documentation implies:
http://godoc.org/gopkg.in/v1/docs#hdr-Version_zero

I can see there is no hard and fast solution for this. If Revel depends on
github.com/revel, it is at the mercy of the state of files of that version.
How can you ensure v0.9.1 is looking at v0.9.1 without specifying that
version internally?

This is a difficult thing to maintain externally and internally. I could
see a dependency traversing tool that goes through and renames imports to
make this all work. That's overlapping functionality with
https://github.com/tools/godep though.

On Thu, Mar 27, 2014 at 1:27 AM, Brenden Soares notifications@github.comwrote:

Using a latest aka v0 version in the import path would defeat the purpose
of version locking, wouldn't it? The point is to create a dependency on a
specific version, right?

Reply to this email directly or view it on GitHubhttps://github.com//issues/564#issuecomment-38772662
.

[brendensoares]

It seems for now we'll have to continue without version locking, but we're very interested in finding an elegant and effective solution.