6 ms·

> What kind of language recommends[0] with a straight face that you just duplicate your entire codebase into a v2/ subdirectory? Not Go at least. You misunders

> What kind of language recommends[0] with a straight face that you just duplicate your entire codebase into a v2/ subdirectory? Not Go at least. You misunderstood the post completely. Here is an example of how you are supposed to change the import path for subsequent major versions (that is, backwards incompatible versions): https://github.com/jackc/pgx/blob/3599f646293c1b0d381214ab26895abb9f605bc8/go.mod#L1 https://github.com/jackc/pgx/blob/3599f646293c1b0d381214ab26... A one-line change to your modfile and the import path is changed.

cdogl 5y ago
Thanks for this informed comment. A timely reminder to me to read TFA, because I took parent comment at face value on first reading.
nvarsj 5y ago
That's incorrect. The go blog recommends copying your entire project into a v2 folder. They do suggest you can use tags/branches instead, but it will cause problems with GOPATH projects.
- deleted 5y ago
  [deleted]
- atombender 5y ago
  It recommends this, sure, but there's no need for it. Doing so would be purely for backwards compatibility with older versions of Go tools that don't understand modules and rely on GOPATH. If you don't need to support older tools, then there's absolutely no need to copy anything.
  - ruraljuror 5y ago
    Maybe I'm missing something, but I think there is a need. If your code imports dependencies A & B and they depend on C at two different versions, how can you handle this unless C is structured with versioned dirs?
    - atombender 5y ago
      Go does not map the module path directly to a file system path. You can import v1 and v2 at the same time because they have different module names. In other words, this is allowed: $ go get github.com/linkedin/goavro@v1.0.5 $ go get github.com/linkedin/goavro/v2@v2.10.1 Then: $ go list -m ... | grep goavro github.com/linkedin/goavro v1.0.5 github.com/linkedin/goavro/v2 v2.10.1 Version 1 has a go.mod that declares: module github.com/linkedin/goavro and version 2 has a go.mod that declares: module github.com/linkedin/goavro/v2 but both have their Go files located in the root of the repository.
- arghwhat 5y ago
  GOPATH is luckily soon dead.
  - throwaway894345 5y ago
    Which is kind of remarkable. Python still seems to try to support every package manager and format that ever existed, and that’s part of why packaging in Python is so awful. Nice to see a language that can move forward with such a major change in such a short time and with relatively little pain.
    - btmcnellis 5y ago
      Python is a lot older and a lot more widely used, so it’s not as easy to just change things.
      - eikenberry 5y ago
        Python3 is pretty close to Go in age and was a purposely compatibility breaking, so it could have easily changed things at that point and they definitely knew about the problem at that point.
        mkl95 5y ago
        The difference between 2 and 3 is way smaller than people make it out to be. I migrated a large Python 2.7 project to Python 3.8 and it wasn't a particularly painful experience. I feel that way more effort should have been directed at making 2 and 3 compatible.
        throwaway894345 5y ago
        It took more than a decade for the ecosystem to migrate. IIRC, a lot of effort went into making them compatible, but some things are just fundamentally incompatible and also very difficult to automate (e.g., string encodings).
ithkuil 5y ago
> A one-line change to your modfile and the import path is changed. Another detail: since your import path change also affects internal imports between packages within your module, you also need to fixup a bunch of .go files in your repo (worst case all of them). I still think it's not a big deal (it's all pretty straightforward non-magic). Just a small nitpick that it's not just one go.mod change.
- arghwhat 5y ago
  Yes, any consumer must pick the new import path, although that is true regardless of strategy.
nemetroid 5y ago
> Not Go at least. You misunderstood the post completely. What? From the post: > The recommended strategy is to develop v2+ modules in a directory named after the major version suffix. > … > We recommend that module authors follow this strategy as long as they have users developing in GOPATH mode. Although with a reservation, they clearly do recommend it.
- Philip-J-Fry 5y ago
  "As long as they have users developing in GOPATH mode." It's documentation written when GOPATH was still a widely used for development. I think nowadays it's less of a concern to have a module first code base with GOPATH unsupported. It's nicer to use a V2 branch. Or delegate V1 to a V1 branch and maintain V2 in master.
  - nemetroid 5y ago
    I’m not disputing that things may have changed since the post was written. But the comment I responded to claimed that the linked post didn’t recommend copy-into-subdirectory, which it clearly does.
  - s17n 5y ago
    How is a branch nicer than a subdirectory? Off the top of my head, it seems like backporting bugfixes might be easier using a branch (if you're lucky, you can just cherrypick the commit and it will work) - any other reasons?

cdogl 5y ago

Thanks for this informed comment. A timely reminder to me to read TFA, because I took parent comment at face value on first reading.

nvarsj 5y ago

That's incorrect. The go blog recommends copying your entire project into a v2 folder. They do suggest you can use tags/branches instead, but it will cause problems with GOPATH projects.

deleted 5y ago
[deleted]
atombender 5y ago
It recommends this, sure, but there's no need for it. Doing so would be purely for backwards compatibility with older versions of Go tools that don't understand modules and rely on GOPATH. If you don't need to support older tools, then there's absolutely no need to copy anything.
- ruraljuror 5y ago
  Maybe I'm missing something, but I think there is a need. If your code imports dependencies A & B and they depend on C at two different versions, how can you handle this unless C is structured with versioned dirs?
  - atombender 5y ago
    Go does not map the module path directly to a file system path. You can import v1 and v2 at the same time because they have different module names. In other words, this is allowed: $ go get github.com/linkedin/goavro@v1.0.5 $ go get github.com/linkedin/goavro/v2@v2.10.1 Then: $ go list -m ... | grep goavro github.com/linkedin/goavro v1.0.5 github.com/linkedin/goavro/v2 v2.10.1 Version 1 has a go.mod that declares: module github.com/linkedin/goavro and version 2 has a go.mod that declares: module github.com/linkedin/goavro/v2 but both have their Go files located in the root of the repository.
arghwhat 5y ago
GOPATH is luckily soon dead.
- throwaway894345 5y ago
  Which is kind of remarkable. Python still seems to try to support every package manager and format that ever existed, and that’s part of why packaging in Python is so awful. Nice to see a language that can move forward with such a major change in such a short time and with relatively little pain.
  - btmcnellis 5y ago
    Python is a lot older and a lot more widely used, so it’s not as easy to just change things.
    - eikenberry 5y ago
      Python3 is pretty close to Go in age and was a purposely compatibility breaking, so it could have easily changed things at that point and they definitely knew about the problem at that point.
      - mkl95 5y ago
        The difference between 2 and 3 is way smaller than people make it out to be. I migrated a large Python 2.7 project to Python 3.8 and it wasn't a particularly painful experience. I feel that way more effort should have been directed at making 2 and 3 compatible.
        throwaway894345 5y ago
        It took more than a decade for the ecosystem to migrate. IIRC, a lot of effort went into making them compatible, but some things are just fundamentally incompatible and also very difficult to automate (e.g., string encodings).

ithkuil 5y ago

> A one-line change to your modfile and the import path is changed. Another detail: since your import path change also affects internal imports between packages within your module, you also need to fixup a bunch of .go files in your repo (worst case all of them). I still think it's not a big deal (it's all pretty straightforward non-magic). Just a small nitpick that it's not just one go.mod change.

arghwhat 5y ago
Yes, any consumer must pick the new import path, although that is true regardless of strategy.

nemetroid 5y ago

> Not Go at least. You misunderstood the post completely. What? From the post: > The recommended strategy is to develop v2+ modules in a directory named after the major version suffix. > … > We recommend that module authors follow this strategy as long as they have users developing in GOPATH mode. Although with a reservation, they clearly do recommend it.

Philip-J-Fry 5y ago
"As long as they have users developing in GOPATH mode." It's documentation written when GOPATH was still a widely used for development. I think nowadays it's less of a concern to have a module first code base with GOPATH unsupported. It's nicer to use a V2 branch. Or delegate V1 to a V1 branch and maintain V2 in master.
- nemetroid 5y ago
  I’m not disputing that things may have changed since the post was written. But the comment I responded to claimed that the linked post didn’t recommend copy-into-subdirectory, which it clearly does.
- s17n 5y ago
  How is a branch nicer than a subdirectory? Off the top of my head, it seems like backporting bugfixes might be easier using a branch (if you're lucky, you can just cherrypick the commit and it will work) - any other reasons?