The first one is not blocking for us, it's blocking for golang/go if
they care, but gonum/internal and all the other old packages are
deprecated and won't be changed.
The second one is troubling. I think pinging is in order. There is no
justification for forcing us to change this.
--
You received this message because you are subscribed to the Google Groups "gonum-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gonum-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thanks Dan for pinging on the issue.I haven't been on top of this as I should be, so I'd like to check I understand.- As of right now, it seems like we need to break our current system, instead of "gonum.org/v1/gonum", we would likely just have "gonum.org/gonum".
- We currently don't have any versions at all. While we would like to be at version 1, I don't think we're there yet (though we're getting closer). These changes do imply we should try and have some minor version tags, 0.1, 0.2 etc. to at least work with vgo somewhat
- Let's say we do get a version 1, but in the future we hove to a version 2. This would look like "gonum.org/gonum/v2", with imports like "gonum.org/gonum/v2/mat" . It would be represented on git with a version tag, but the code would still live in "github.com/gonum/gonum"?
- Let's say we eventually make the root `gonum` a package for some reason. How would a user use the v2 version of this? It seems like the import path would be simply "gonum.org/gonum/v2", so does that mean all import statements have to be written as `import gonum "gonum.org/gonum/v2" `? That seems really ugly.
On May 22, 2018, at 10:10 AM, Sebastien Binet <bi...@cern.ch> wrote:On Tue, May 22, 2018 at 5:57 PM Brendan Tracey <tracey....@gmail.com> wrote:Thanks Dan for pinging on the issue.I haven't been on top of this as I should be, so I'd like to check I understand.- As of right now, it seems like we need to break our current system, instead of "gonum.org/v1/gonum", we would likely just have "gonum.org/gonum".I think I'd rather have it `gonum.org/x/gonum` and `gonum.org/x/plot` (to more easily organize handlers and end-points on the gonum.org web site end).
but, yeah, if nobody changes the current behaviour of `vgo` (or go-1.11), dropping `gonum.org/v1/xxx` would be required.- We currently don't have any versions at all. While we would like to be at version 1, I don't think we're there yet (though we're getting closer). These changes do imply we should try and have some minor version tags, 0.1, 0.2 etc. to at least work with vgo somewhatyes.but we should tag them as v0.1.0, v0.2.0, etc.. to better follow what vgo expects.(for go-hep, I was using v0.1, v0.2, ... but this confused vgo. had to add an extra `.0`...)- Let's say we do get a version 1, but in the future we hove to a version 2. This would look like "gonum.org/gonum/v2", with imports like "gonum.org/gonum/v2/mat" . It would be represented on git with a version tag, but the code would still live in "github.com/gonum/gonum"?yes.- Let's say we eventually make the root `gonum` a package for some reason. How would a user use the v2 version of this? It seems like the import path would be simply "gonum.org/gonum/v2", so does that mean all import statements have to be written as `import gonum "gonum.org/gonum/v2" `? That seems really ugly.I believe one would just have to write:```import ()```
but I am not completely sure about the `mat` import.also, the vgo story for mono-repos isn't completely clear to me:- one go.mod file for each "sub" package ?- one go.mod file per mono-repo, at the root ?- what happens if somebody tries to:```import ()```assuming stat/v3 is compatible with mat/v2, is it legit? wouldn't this confuse vgo's storage somehow?
my/thing/sub/pkg
, my/thing/v2/sub/pkg
, and my/thing/v3/sub/pkg
come from major versions v1, v2, and v3 of the module my/thing
,
but the build treats them simply as three different packages.”On May 22, 2018, at 10:10 AM, Sebastien Binet <bi...@cern.ch> wrote:On Tue, May 22, 2018 at 5:57 PM Brendan Tracey <tracey....@gmail.com> wrote:Thanks Dan for pinging on the issue.I haven't been on top of this as I should be, so I'd like to check I understand.- As of right now, it seems like we need to break our current system, instead of "gonum.org/v1/gonum", we would likely just have "gonum.org/gonum".I think I'd rather have it `gonum.org/x/gonum` and `gonum.org/x/plot` (to more easily organize handlers and end-points on the gonum.org web site end).I agree with the principle, though I don’t know about “x”, as in go land that is “experimental”. We could have “std” or “c” (for code) or something.
My confusion about the bullet point is wrong, as I misread the Go spec. The Go spec says the default identifier is what is listed in the package clause in the imported package, and has nothing to do with the identifier used in the import clause. So, “mat” would still have a default import of “mat” no matter what you tack on to the end.
--
You received this message because you are subscribed to the Google Groups "gonum-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gonum-dev+...@googlegroups.com.
The first one is not blocking for us, it's blocking for golang/go if
they care, but gonum/internal and all the other old packages are
deprecated and won't be changed.
The second one is troubling. I think pinging is in order. There is no
justification for forcing us to change this.