Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go/types: move to go.exp subrepo #4870

Closed
rsc opened this issue Feb 21, 2013 · 19 comments
Closed

go/types: move to go.exp subrepo #4870

rsc opened this issue Feb 21, 2013 · 19 comments
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Feb 21, 2013

Not 100% sure we want to commit to the current go/types API without more usage.
Wait until later.
@rsc
Copy link
Contributor Author

rsc commented Feb 21, 2013

Comment 1:

(That is, wait until closer to the release to decide.)

@robpike
Copy link
Contributor

robpike commented Mar 5, 2013

Comment 2:

It will stay but will not be part of the initial Go 1.1 release. The API is complex and
not used enough yet to provide the necessary level of confidence.

Labels changed: removed go1.1.

Status changed to LongTerm.

@rsc
Copy link
Contributor Author

rsc commented Mar 5, 2013

Comment 3:

What does it mean to stay but not be part of Go 1.1?
The dist tool will have to be updated to delete it from the tree when
preparing the release.

@robpike
Copy link
Contributor

robpike commented Mar 5, 2013

Comment 4:

It means that tools that depend on it will have to be released in a version that does
not have the dependency. The dist tool will need to exclude it, yes, and vet will need
to be patched to an earlier rev.

@rsc
Copy link
Contributor Author

rsc commented Mar 5, 2013

Comment 5:

Special casing this is going to be a significant burden on the distribution
code: it's going to be mostly untested and break when we try to do the
actual distribution. I'd much rather find a mechanism that doesn't require
last-minute tweaking of the tree.
Here is an alternative:
1. Move go/types to the go.exp subrepo.
2. Arrange so that cmd/vet has all its references to go/types in one file
that can be dropped from the build. Mark that file with // +build gotypes.
3. People who want the typed vet run 'go install -tags gotypes cmd/vet'.
It also gives people who have Go 1.1 and want to try go/types a way to do
so.
Russ

@bradfitz
Copy link
Contributor

bradfitz commented Mar 5, 2013

Comment 6:

(3) of course requires fixing issue #4443, which is marked to be fixed anyway.

@rsc
Copy link
Contributor Author

rsc commented Mar 5, 2013

Comment 7:

And people can run 'go install -a -tags gotypes cmd/vet' until it is fixed.

@robpike
Copy link
Contributor

robpike commented Mar 5, 2013

Comment 8:

Labels changed: added go1.1.

@griesemer
Copy link
Contributor

Comment 9:

Just for the record:
1) The main reason for excluding it from Go 1.1 is that we might find issues that
require the API to change in non-compatible ways.
2) There's another alternative: Allow it in Go 1.1 but permit its API to change if
necessary (with a big disclaimer in the file, of course). I think that would actually be
the easiest from a release and testing point of view. There is a danger of setting an
unfortunate precedent.

Labels changed: removed go1.1.

@rsc
Copy link
Contributor Author

rsc commented Mar 5, 2013

Comment 10:

Re-adding Go 1.1 label. The label does not mean go/types is in Go 1.1. It means this is
something we need to resolve before Go 1.1.

Labels changed: added go1.1.

@robpike
Copy link
Contributor

robpike commented Mar 5, 2013

Comment 11:

i'd already added the label. well, it's there now, so that's ok.

@minux
Copy link
Member

minux commented Mar 5, 2013

Comment 12:

move go/types to cmd/vet/gotype
so that it's in Go 1.1 but excluded from API freeze?
we add those warnings, but people are free to use it
if they want.

@bradfitz
Copy link
Contributor

bradfitz commented Mar 5, 2013

Comment 13:

You could include it in Go 1.1, but make main sign a disclaimer that they know it's
experimental:
package main
import (
  "go/exp"  // a new package
  "github.com/bob/foo"  // which itself imports go/types, included in Go 1.1
)
func main() {
   // Enable the experimental go/types API.  The Enable call only
   // works from main.main.  If go/types is used without being enabled,
   // it panics.
   exp.Enable("go/types")
   foo.Something() // ... which uses go/types. But foo can't Enable itself. Only main can.
}
By making main declare that, it prevents:
  user A's main -> user B's foo -> go/types 1.1 (works)
  user A's main -> user B's foo -> go/types 1.2 (explodes)
... and surprising user A, who didn't know how user B's foo was implemented.

@robpike
Copy link
Contributor

robpike commented Mar 6, 2013

Comment 14:

https://golang.org/cl/7528044 adds -tags gotypes to the build, so vet's
conditional compilation is configured to use go/types. Remove before Go 1.1

@rsc
Copy link
Contributor Author

rsc commented Mar 11, 2013

Comment 15:

My understanding is that we're close to being able to move go/types into go.exp/types.

@griesemer
Copy link
Contributor

Comment 16:

Correct. There's a pending CL 7432051 which I am waiting for review. Once it's in, I
have no open files in go/types and we can move it.

@robpike
Copy link
Contributor

robpike commented Mar 12, 2013

Comment 17:

This issue was closed by revision golang/exp@38d2410.

Status changed to Fixed.

@davecheney
Copy link
Contributor

@griesemer
Copy link
Contributor

Comment 19:

pending CL: 7554044

@rsc rsc added fixed labels Mar 12, 2013
zend pushed a commit to go-src/inotify that referenced this issue Apr 3, 2015
@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants