Add go.mod file

[nicpottier]

Perhaps you've been following the discussion around the future of go dependency management?
https://research.swtch.com/vgo

Anyways, a few unrelated people, including me have tried to play with this experiment in our own projects and we are running into problems import chi due to it not having a go.mod file properly advertising the major version as v3.

Any chance chi could partake in this experiment?

I'm willing to give creating a proper chi go.mod file a go in a PR if so.

[VojtechVitek]

I'm down. What do you think @pkieltyka?

[pkieltyka]

I’m down too

[nicpottier]

After doing some more reading (the dev and nuts golang mailing lists have some interesting conversations) I realize it isn't going to be so easy. (also see latest installment here: https://research.swtch.com/vgo-module)

All internal references to go-chi would have to be changed to use a v3 import style.

IE, from my understanding, everywhere where we currently do:

import "github.com/go-chi/chi"

Would have to change to:

import "github.com/go-chi/v3/chi"

That isn't THAT many places in the codebase, but would break non vgo users. So may make sense to give the paint some time to dry on this proposal to see what the community decides is the best practice for existing non v1 modules.

[nicpottier]

Having pondered Russ's latest post a few minutes, I think the answer will be, create a /v3 subdirectory in our repo and copy all code in there. We'd have to update both the root and v3 copies until vgo adoption hits critical mass, but that provides a backwards compatible way of having both vgo and go compatible versions as I understand it.

[vektah]

I like the idea of minimal version selection and removing the distinction between lock and manifest files is great.

But If every library needs to change then perhaps this idea needs more thought?

[nicpottier]

I think this is a bit of a big bet by the go authors that we, the go ecosystem, need to take semantic versioning seriously, and that major version changes that aren't backwards compatible should be thought about carefully. The transition does indeed sound painful but I think there could be something really special to it if, especially if they follow through on their ideas of creating a go release command that helps you figure out what your next version should be. Kind of gofmt it might create a universal culture of excellent versioning moving forward.

That said, discussing the pros and cons of vgo belongs on the golang list more than here.

[pkieltyka]

I think I’ll hold off with chi until I have more time to dive into the subject. I’m a little busy at the moment with another project. I’ll let others take lead on this but since it’s so new I’d recommend to see how other packages adopt these ideas first

[nicpottier]

Yep, I think that makes sense.

For any brave explorers running in this in the future, you can add a chi dependency in your go.mod and use it as you always have with the below: (update the timestamp and hash to the latest go-chi release commit)

require(
    "github.com/go-chi/chi" v0.0.0-20180202194135-e223a795a06a
)

[cryptix]

From looking at https://github.com/peterbourgon/vmain and /vtest, I don't think the actual version folder is needed.

[nicpottier]

It does if you want it to work across both go and vgo, because internal dependencies need to use the folder, ie this part:
https://github.com/peterbourgon/vtest/blob/master/foo/foo.go

[kron4eg]

Chi could have new major release v4, which will address this "1 import path == 1 major version" requirement...

[nicpottier]

@kron4eg ya that's probably the cleanest way forward.

[Gyllsdorff]

Just keep in mind that vgo is a proposal, not yet accepted, still changing and a prototype so implementing it now might be kind of premature. If chi decides to go with the "v3 subfolder in-sync with the rest of the repo" idea there will be a major risk that the "/v3" folder will end-up out of sync with the rest of the code and it will require effort and changes in all incoming PR:s.

People where certain dep would be merged into golang but we all know how that ended up. I would consider waiting until vgo becomes bit more mature.

https://github.com/golang/go/wiki/vgo#current-state

Current state
Currently vgo is in active development / prototype phase. It has some rough edges, changes will happen at a rapid pace.

[egtann]

vgo was just accepted: golang/go#24301 (comment)

It's worth revisiting this issue.