11 ms·

The v2 library suffix on the package path seems rather hackish. Feels like it would have been better to use a different delineating character instead of a slas

by kromem 8y ago

The v2 library suffix on the package path seems rather hackish. Feels like it would have been better to use a different delineating character instead of a slash to make it abundantly clear at a glance that it's effectively a major version tag and not a subpackage. Other than that, seems relatively straightforward. Hope this is the last "new and completely different" attempt to tackle dependency management in Go.

cube2222 8y ago
It's kinda both. The point is, that major versions should (by the philosophy of vgo) effectively be different packages and be handled like different packages. Check out Russ's blog post series: https://research.swtch.com/vgo https://research.swtch.com/vgo
- nanimo 8y ago
  I personally like that philosophy, but I wonder if it's in Go's best interests to ignore the desires of the people who don't like, or perhaps aren't even aware of, that reasoning.
BillinghamJ 8y ago
Particularly the fact that it only applies after the second version. If we're going to require /v2, /v3, etc - shouldn't we also require /v1 for the first? Also it's unclear how initial development (as per server) is to be handled. If the first few versions are v0.1.0, v0.2.0, etc. - how are these handled on the import paths. What if a package URL actually contains "/v2" at the end, but this isn't actually referring to the version and should be used when fetching the package. Seems very odd. Agree that it should have been more like "@2". What if you want to include two different minor versions, for example, as you can include two different major ones. Is that possible/allowed?
- cube2222 8y ago
  Requiring v1 would break backwards compatibility. If you create a new library, feel free to do that. The point is to treat different major versions as different packages, enough obviously lets you use multiple major versions in your project. v0 and v1 are treated as the same package, you're supposed to use v0 as long as you're adapting to vgo / potentially doing breaking changes and use v1 when you know you'll keep a stability guarantee. As I mentioned in the sibling comment, it's all described in Russ's blog post series, long, but well worth the read: https://research.swtch.com/vgo https://research.swtch.com/vgo
- pests 8y ago
  > If the first few versions are v0.1.0, v0.2.0, etc. - how are these handled on the import paths. This was answered in the post. It's handled in the mod file and not via import path. Import path only changes when there is breaking changes, ie: a major bump and a new /v# for the import path. Upgrade minor or patch to most recent: go get -u Upgrade patch to most recent: go get -u=patch Upgrade to specific version: go get package@version
Athas 8y ago
I agree. It seems to be based on having quite specific information about the structure of the package path based on the service it references. For instance, I assume that github.com/user/v2 will refer to version 0 or 1 of the 'v2' repository. When I wrote my own vgo-inspired package manager[0] I changed the handling of major versions in package paths such that they are separated by an @-sign. While github.com/user/v2@v3 still looks silly, I think it is less confusing. [0]: https://futhark.readthedocs.io/en/latest/package-management.html https://futhark.readthedocs.io/en/latest/package-management....
crabmusket 8y ago
I was very surprised at the way they decided to go for `v2`. It seems kind counter to the Go philosophy so far of simplicity, predictability, etc. Now I can't just look at the imports list and apply a very simple mental rule to know what names are in scope - there's this hacky exception which magically changes the rule for very specific name schemes.
- nemo1618 8y ago
  If you're implying that "import foo" always puts foo in scope, that's never been true -- the package name doesn't need to match the last element of the path. Granted, you can count on it being true in 90% of cases, but I think "/v2" will quickly become unsurprising, the same way we expect "import go-foo" to add the name foo, not go-foo.

by kromem 8y ago

cube2222 8y ago

It's kinda both. The point is, that major versions should (by the philosophy of vgo) effectively be different packages and be handled like different packages. Check out Russ's blog post series: https://research.swtch.com/vgo https://research.swtch.com/vgo

nanimo 8y ago
I personally like that philosophy, but I wonder if it's in Go's best interests to ignore the desires of the people who don't like, or perhaps aren't even aware of, that reasoning.

BillinghamJ 8y ago

Particularly the fact that it only applies after the second version. If we're going to require /v2, /v3, etc - shouldn't we also require /v1 for the first? Also it's unclear how initial development (as per server) is to be handled. If the first few versions are v0.1.0, v0.2.0, etc. - how are these handled on the import paths. What if a package URL actually contains "/v2" at the end, but this isn't actually referring to the version and should be used when fetching the package. Seems very odd. Agree that it should have been more like "@2". What if you want to include two different minor versions, for example, as you can include two different major ones. Is that possible/allowed?

cube2222 8y ago
Requiring v1 would break backwards compatibility. If you create a new library, feel free to do that. The point is to treat different major versions as different packages, enough obviously lets you use multiple major versions in your project. v0 and v1 are treated as the same package, you're supposed to use v0 as long as you're adapting to vgo / potentially doing breaking changes and use v1 when you know you'll keep a stability guarantee. As I mentioned in the sibling comment, it's all described in Russ's blog post series, long, but well worth the read: https://research.swtch.com/vgo https://research.swtch.com/vgo
pests 8y ago
> If the first few versions are v0.1.0, v0.2.0, etc. - how are these handled on the import paths. This was answered in the post. It's handled in the mod file and not via import path. Import path only changes when there is breaking changes, ie: a major bump and a new /v# for the import path. Upgrade minor or patch to most recent: go get -u Upgrade patch to most recent: go get -u=patch Upgrade to specific version: go get package@version

Athas 8y ago

I agree. It seems to be based on having quite specific information about the structure of the package path based on the service it references. For instance, I assume that github.com/user/v2 will refer to version 0 or 1 of the 'v2' repository. When I wrote my own vgo-inspired package manager[0] I changed the handling of major versions in package paths such that they are separated by an @-sign. While github.com/user/v2@v3 still looks silly, I think it is less confusing. [0]: https://futhark.readthedocs.io/en/latest/package-management.html https://futhark.readthedocs.io/en/latest/package-management....

crabmusket 8y ago

I was very surprised at the way they decided to go for `v2`. It seems kind counter to the Go philosophy so far of simplicity, predictability, etc. Now I can't just look at the imports list and apply a very simple mental rule to know what names are in scope - there's this hacky exception which magically changes the rule for very specific name schemes.

nemo1618 8y ago
If you're implying that "import foo" always puts foo in scope, that's never been true -- the package name doesn't need to match the last element of the path. Granted, you can count on it being true in 90% of cases, but I think "/v2" will quickly become unsurprising, the same way we expect "import go-foo" to add the name foo, not go-foo.