testscript: move to golang or other 'official' org?

[ldemailly]

Maybe more a question than an issue but why isn't this repo like

https://github.com/golang/ ..

or

https://github.com/google/go-cmdtest

ie under an org rather than an individual? I think testscript is awesome and it would make it easier to adopt and publicize under a. well known (or even its own) org ?

[mvdan]

See https://github.com/go-quicktest/qt, which I understand @frankban and @rogpeppe want to switch to at some point. Moving to an org before then is likely not a good idea, as it would be a breaking change.

[ldemailly]

Thanks for the quick response. So far qt doesn't seem to have txtar etc support but are you saying it'll be added there? (I didn't see it mentioned in the v1 issue either)

[mvdan]

That new location would be for quicktest, which is what you asked for. Other parts of go-internal are now being exposed as libraries by upstream, like x/tools/txtar, so I think the rest of go-internal will be deprecated over time

[ldemailly]

I am asking specifically about testscript ie a way to test go cli

[mvdan]

Right, I got confused between testscript and quicktest. I don't think there are plans to move it to an org, but @rogpeppe can always clarify.

[ldemailly]

thoughts?

[bep]

I agree that this deserves some broader audience. I stumbled upon this "by accident" and txtar and testscript have been (in that order) the most time saving new "things" I have added to my tool box the last decade.

[myitcv]

This is sort of happening but in a slightly different form to what you might imagine. The following packages already exist in a more "official" namespace:

golang.org/x/mod/modfile
golang.org/x/mod/module
golang.org/x/mod/semver
golang.org/x/tools/txtar

The testscript portion was carved out of cmd/go internals into https://github.com/golang/go/tree/master/src/cmd/go/internal/script. That is, granted, still internal. But at least moving to a more reusable state.

My main question, @ldemailly and @bep, is: what are you trying to solve for by moving this to a more official org?

Because I'm not clear why its current location precludes such publicity, e.g.

https://bitfieldconsulting.com/golang/test-scripts

cc @bitfield for thoughts too

[bep]

My main question, @ldemailly and @bep, is: what are you trying to solve for by moving this to a more official org?

My comment was more general. I think the testscript package should be a first citizen of Go's tool kit ... somehow. They added fuzzing as testing.F, they should consider something that could fit the testscript in there as well.

[bitfield]

As @myitcv says, testscript has already been featured on the Bitfield Consulting blog, and there's simply no higher accolade than that. Mere incorporation in the standard library would almost seem like an anti-climax, wouldn't it?

That said, I'd support such a proposal, but the Go issue tracker would be the place to make it, I think.

I also wouldn't be too sad if it didn't happen. There's a certain freedom that comes with being "unofficial". Of course, if the Go team admired this version of testscript so much that they wanted to fork it and put it under their own org, I'm sure they'd be very welcome. I believe the licence permits this.

[mvdan]

Hosting it somewhere like golang.org/x/tools means that people like Bryan at the Go team have to guarantee backwards compatibility and maintain it for third party users. They are spread pretty thin as-is, which is why people like Roger stepped up to do the work.

I'd personally agree that, long-term, it would be nice to have it in a better place. And, ideally, packages like cmd/go would use the same testscript package as third party projects. But I also don't see an immediate need to rush that. Any such move would almost certainly break all existing testscript users, and that's not the kind of breakage that we want to do more than once every five or ten years :)

[ldemailly]

what are you trying to solve for by moving this to a more official org?

That the import would not look like someone's random personal project (and yes there are random projects under orgs too and also if you look you can see this is maintained etc but still google/x would be an easy sell at work for instance)

Also personally I would like to see just testscript at the top level not a bunch of other things mixed with it. (I actually tried that in a fork but it's not pretty)

Lastly I don't think a rename "breaks" people, they can use the older version until ready to change their import

[thepudds]

I think the place where a decision for "testscript should be exposed under an official Go repo" would be under a proposal on the Go issue tracker... but there would be work to reconcile the two versions, and some things likely would get dropped in the interest of simplicity if it were to happen at all.

I think this repo is what it says on the tin -- an "opinionated selection of internal packages and functionality from the Go standard library".

The fact that it is outside the Go organization has allowed it to diverge slightly in a thoughtful and tasteful way (IMO), and that has happened in a way that would not have been as quick (or even have happened at all in some cases) if it was under an official Go repo. Also, rogpeppe/go-internal is cited by the core Go team as an example of a good success in other proposal discussions of "hey, can we expose internal package foo under golang.org/x".

Moving to golang.org/x would help trustworthiness from a consumer perspective, but by itself does not make it widely known. (What percentage of gophers know about golang.org/x/tools/txtar for example)? Of course, trustworthiness increases adoption, and increased adoption helps awareness build over time.

One example candidate location could be https://github.com/pkg. (That said, I don't know if that is an enormous improvement over current situation, including if you browse https://github.com/orgs/pkg/repositories, it's unlikely that you recognize all of them -- in other words, just being under https://github.com/pkg by itself does not make something well-known).

Also personally I would like to see just testscript at the top level not a bunch of other things mixed with it. (I actually tried that in a fork but it's not pretty)

FWIW, https://github.com/rogpeppe/testscript exists. (But that is an older version, including because time is a finite resource).

That the import would not look like someone's random personal project (and yes there are random projects under orgs too and also if you look you can see this is maintained etc but still google/x would be an easy sell at work for instance)

Personally, I find github.com/rogpeppe/go-internal more trustworthy at a glance than github.com/some-testscript-org. @rogpeppe has been around since the very early days of Go, and if you peel back the layers of history, he is actually behind an amazing number of ideas in Go, although he is of course quite modest about it 😅.

[thepudds]

FWIW, I sent a PR #225 that might help (slightly 😅) regarding a few of the concerns raised here.

Not perfect, but maybe something along those lines might be a small improvement as people initially evaluate this repo.

[myitcv]

My comment was more general. I think the testscript package should be a first citizen of Go's tool kit ... somehow. They added fuzzing as testing.F, they should consider something that could fit the testscript in there as well.

@bep thanks. That makes a lot of sense, and wouldn't meet with any objection from me. As @mvdan pointed out, such a "move" would require a concerted effort from the Go team and folks here. Again, nothing to stop that from happening, just that nothing has started that process yet!

I'll note that @bcmills factored out some of the cmd/go internals to https://github.com/golang/go/tree/master/src/cmd/go/internal/script.

As @bitfield and @mvdan noted, I fully agree with:

That said, I'd support such a proposal, but the Go issue tracker would be the place to make it, I think.

I'm not aware of an open issue in the Go issue tracker to propose such a move. One of the first steps would be to create such an issue. I can't speak on behalf of @rogpeppe and @mvdan (who also maintain this project) but I would not object to someone raising such an issue. There is not restriction on anyone raising such an issue.

But as @mvdan and others have pointed out, I don't think it's necessarily clear that moving/adopting testscript would be a clear net win. But again, raising an issue in the Go issue tracker would help to flush out the various points for and against.

On a personal note, the fact that I (for one) have not created such an issue in the Go issue tracker to "move" testscript does not indicate a lack of willingness to support such a move. Nor does it indicate that I think such a "move" wouldn't work. Rather that right now, to me, there is no clear benefit to such a move vs the costs of initiating, effecting and maintaining such a move. To be fair, those points have not be aired anywhere public, it's sort of implicit in the fact that I (for one, again) haven't created such an issue. As the Go team will attest I'm not afraid of creating new issues 😄!

That the import would not look like someone's random personal project (and yes there are random projects under orgs too and also if you look you can see this is maintained etc but still google/x would be an easy sell at work for instance)

@ldemailly this is a fair point. But I think it's very easily overcome by exactly what @thepudds suggested in https://github.com/rogpeppe/go-internal/issues/196#issuecomment-1537441751. Indeed thank you, @thepudds, for raising #225. That seems to help address a number of the points brought up here.