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.

[mwf]

Hi, guys!

I was experimenting a bit around vgo this days. I'm also looking forward adopting go.mod and vgo on early stage to collect all possible bugs in advance, before go1.11 is released :)

I played around the fork of chi and it seems there is a way for both keeping version 3.x and adopting go.mod and new semver imports - just adding a v3 symlink to the project root. Old go versions are happy - they are able to find the "new" imports out of box.

Please take a look at my fork https://github.com/mwf/chi and a test project https://github.com/mwf/goplay/tree/master/vgo/chi

There are two options for users:

• to use vgo as a vendoring tool (vgo mod -vendor) - vendor folder is populated in a way to make happy old go
• just use the new version with their existing vendoring tools, symlink will make the magic - you could check it checking-out my master branch in the $GOPATH.

What do you think about it? If it seems OK for you I'll be glad to make a PR :)

[mwf]

Opened a PR in case you consider it a good way to go.

[mwf]

golang/go#26238 is closed, and you can try go1.11beta2 - we don't need go.mod to make the go1.11 users happy - old v2+ repos work with new go out-of-box.

cd `mktemp -d`
go mod -init -module example.com/hello
cat <<EOD >hello.go
package main

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

func main() {
        _ = chi.NewRouter()
}
EOD
go build

go.mod ends up as:

$ cat go.mod
module example.com/hello

require github.com/go-chi/chi v3.3.2+incompatible

So we can add go.mod in chi v4, just when you decide it's a good time for import path change.

[thepudds]

FYI, I added a comment golang/go#25967 (comment) to the go issue @VojtechVitek had spawned from this go-chi issue.

In that comment I attempted to explain the new (and better!) behavior for a user using modules who needs to go get go-chi now that another related issue golang/go#26238 is resolved (as of last week/go11.1beta2), given go-chi is >= v2 and has not converted to modules itself.

edit: sorry! I should have refreshed this issue page before adding my comment here. I now see @mwf just wrote a similar comment as mine here.

[VojtechVitek]

So, as far as I understand, we need to stick with v3.x+incompatible version for now. We can't release go.mod and thus release a new github.com/go-chi/chi/v3 import path, until we're comfortable with breaking builds on Go versions that are not aware of Go modules (pre- 1.9.7 and 1.10.3).

Personally, I'm fine with that for a while.

[VojtechVitek]

Ref. #346

We will add go.mod file eventually in v4.x.x version.

We don't want to add it to v3.x.x, since we don't want to break existing import paths (an extra /v3 suffix in both chi and middleware pkgs).

For now, chi will live on v3.x.x+incompatible versions.

[VojtechVitek]

We're going to add go.mod in chi v4 at #378.

[VojtechVitek]

#302 was rejected by the main chi author. He doesn't like the idea of changing the import paths because of Go modules support (ie. github.com/go-chi/chi/v4) and become a tech support for the confused chi users. So we're keeping it simple and chi stays on +incompatible flag for now.

[theckman]

The Gofrs are also of the same opinion after we bungled adding modules to one of our packages.

@VojtechVitek @pkieltyka As an FYI, when your package version is greater than 1 you must do a major version bump to add modules support. Meaning it will need to be chi v5. We didn't realize this in the Gofrs and was what the bungled addition. We aren't comfortable forcing a major version bump for a still experimental feature.

[freeformz]

FWIW: It's going to be "finalized" for Go 1.13, which is due out this summer.

[pkieltyka]

@freeformz thanks for the note -- are there any changes to the modules sys in the "finalized" version? I'd rather avoid having to uglify the import path with a /v5 path for the sake of not showing +incompatible in the mod file

[theckman]

Sadly, nope. Unless there is some miracle, I believe we're going to be stuck with the Modules system as it exists today. It's pretty disappointing.

[pkieltyka]

got it, so either the mod line is ugly, or the import path is ugly. I opt to have the mod line ugly if we're to settle on one.

unless there are other benefits/reasons I'm not understanding to add a go.mod file ?

[theckman]

Sadly, I'm pretty sure they've put a gun to your head and made this the only way to guarantee major version compatibility. I may need to think through this more, but I believe that without being in Modules if you bump a major version, and someone runs go get -u, it's likely they'll get it and their code will break since they'd pull the next major version.

Edit: is it obvious Modules make me sad?

Edit: I'm now thinking that maybe by putting a require line with a specific SemVer tag may actually make it work, but they'd need to manually bump versions and upgrade (which seems okay to me). Worth testing to verify though.

[thepudds]

@theckman FWIW, I think you are right that a client of go-chi who is using modules and runs go get -u without any arguments would upgrade from, say, github.com/go-chi/chi@v3.0.0+incompatible to something like github.com/go-chi/chi@v4.0.2+incompatible.

I'm now thinking that maybe by putting a require line with a specific SemVer tag may actually make it work, but they'd need to manually bump versions and upgrade (which seems okay to me).

I think you are also right that if a client manually puts something like require github.com/go-chi/chi v3.0.0 or require github.com/go-chi/chi v3.0.0+incompatible into their go.mod, then that is the version they would use (unless there is another require elsewhere for a higher version). A client of go-chi could then manage upgrades from there.

For example, if a client is on github.com/go-chi/chi@v3.0.0+incompatible, they could do something like go get github.com/go-chi/chi@v3 (note the version there ends at v3) to get the latest v3.x.y without crossing a major version. (That is called a "Module Query", which has some flexibility you can read about here if interested).

[thepudds]

FWIW: It's going to be "finalized" for Go 1.13, which is due out this summer.

Side note: enabling module mode by default for the go tool has been slowed down further compared to the prior plan of doing it in Go 1.13. As far as I am aware, the recently updated plan is now to enable module mode by default in 1.14, according to golang/go#31857.

[nicpottier]

Ya, tooling is still pretty painful with modules honestly (the gopls server still has a ways to go) so honestly we probably have a good while before everybody is going to be jumping on that wagon. (we have, but it is painful due to the tools still being early days)

[pkieltyka]

thanks for all the help everyone in figuring out the best approach. From the discussion in golang/go#31857 sounds like waiting for 1.14 will bring a better experience and more potential positive changes, so I'd like to wait until that settles

[freeformz]

FWIW: An import path of github.com/go-chi/chi/v5 will still contain a module named chi and can be used as chi.ExportedThing in code. This exists that so that any number of major versions of a module can be used simultaneously in the same project. i.e. You could use github.com/go-chi/chi/v5 AND github.com/go-chi/chi/v4 (one would need to be renamed locally though) in the same project. For chi, I expect that not to really be a thing, unless a large project is doing a slow migration of various endpoints from version v4 to v5.

[carldunham]

So what is the guidance now, if we are using modules? Stick with 3.3.2? Could some things get back-ported from 4+? Specifically, I am looking for updates in go-chi/jwtauth, but that seems to depend on chi v4.

[theckman]

@carldunham I don't really use Modules, but maybe the replace statement will help?

[carldunham]

@theckman I'm just starting to dip my toes in, but just migrated a big work project to use modules for dependency management. Far different from the publisher side to be sure. So I did think about using replace, just wasn't sure what to replace what with. Will play around with it some more and see what I can do. It generally seems, tho, especially with the package validation features now in 1.13, that such trickery isn't really tolerated. Good ol' draconian Go!

[VojtechVitek]

you can use chi v4 with Go modules out of the box

GO111MODULE=on go get -u github.com/go-chi/chi@v4.0.2

will pull github.com/go-chi/chi@v4.0.2+incompatible

[carldunham]

Indeed. Thanks, @VojtechVitek!