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

cmd/compile: Unclear guidelines on what files/directories are ignored #20337

Closed
sectioneight opened this Issue May 12, 2017 · 11 comments

Comments

Projects
None yet
5 participants
@sectioneight

sectioneight commented May 12, 2017

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.8.1

What operating system and processor architecture are you using (go env)?

darwin x86_64

What did you do?

underscore-test ❯ pwd
/Users/ai/src/go/src/scratch/underscore-test
underscore-test ❯ tree -a
.
├── .dot
│   └── dot.go
├── _underscore
│   └── underscore.go
└── main.go

2 directories, 3 files
underscore-test ❯ cat main.go _underscore/underscore.go .dot/dot.go
package main

import (
        "fmt"
        "scratch/underscore-test/_underscore"

        "scratch/underscore-test/.dot"
)

func main() {
        fmt.Println(underscore.Underscore)
        fmt.Println(dot.Dot)
}
package underscore

// Underscore is the best yo
const Underscore = "_"
package dot

// Dot is a dot
const Dot = "."

What did you expect to see?

I expected a compilation error, given that documentation states that "." and "_" prefixed files will be ignored, however this rule does not seem to apply to directories. I ran into this yesterday with @davecheney, who suggested that I modify golang/dep to skip scanning directories which start with _ or .. Currently we're in a weird situation where files are ignored but directories are not, and I can't find any documentation stating what the source of truth should be. Does golang/dep have the correct behavior, or broken behavior? Will the golang toolchain eventually stop compiling directories that start with . or _?

What did you see instead?

It worked:

underscore-test ❯ go build
underscore-test ❯ echo $?
0
underscore-test ❯ ./underscore-test
_
.
@dcheney-atlassian

This comment has been minimized.

Show comment
Hide comment
@dcheney-atlassian

dcheney-atlassian May 12, 2017

Directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata".

--https://golang.org/cmd/go/#hdr-Description_of_package_lists

dcheney-atlassian commented May 12, 2017

Directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata".

--https://golang.org/cmd/go/#hdr-Description_of_package_lists

@sectioneight

This comment has been minimized.

Show comment
Hide comment
@sectioneight

sectioneight May 12, 2017

Ok, so is it a bug that my example code compiles?

sectioneight commented May 12, 2017

Ok, so is it a bug that my example code compiles?

@sectioneight

This comment has been minimized.

Show comment
Hide comment
@sectioneight

sectioneight May 12, 2017

I guess the underlying question is "is there a difference between things that are ignored by the gotool, and what are valid import paths?". Is that correct?

sectioneight commented May 12, 2017

I guess the underlying question is "is there a difference between things that are ignored by the gotool, and what are valid import paths?". Is that correct?

@dcheney-atlassian

This comment has been minimized.

Show comment
Hide comment
@dcheney-atlassian

dcheney-atlassian May 12, 2017

I guess the underlying question is "is there a difference between things that are ignored by the go tool, and what are valid import paths?".

yes, there is a difference. Those paths will (probably) not show up in go list ./... but can be imported.

dcheney-atlassian commented May 12, 2017

I guess the underlying question is "is there a difference between things that are ignored by the go tool, and what are valid import paths?".

yes, there is a difference. Those paths will (probably) not show up in go list ./... but can be imported.

@sectioneight

This comment has been minimized.

Show comment
Hide comment
@sectioneight

sectioneight May 12, 2017

Ok, so we can close this issue, and I should change golang/dep to recurse into .-prefixed dirs when scanning what source packages are available.

Thanks!

sectioneight commented May 12, 2017

Ok, so we can close this issue, and I should change golang/dep to recurse into .-prefixed dirs when scanning what source packages are available.

Thanks!

@dcheney-atlassian

This comment has been minimized.

Show comment
Hide comment
@dcheney-atlassian

dcheney-atlassian May 12, 2017

@sectioneight I think you should do the opposite

deadwood(~/src/scratch/underscore-test) % go list ./...
scratch/underscore-test
deadwood(~/src/scratch/underscore-test) % find . -type d 
.
./.dot
./_underscore

dcheney-atlassian commented May 12, 2017

@sectioneight I think you should do the opposite

deadwood(~/src/scratch/underscore-test) % go list ./...
scratch/underscore-test
deadwood(~/src/scratch/underscore-test) % find . -type d 
.
./.dot
./_underscore
@sectioneight

This comment has been minimized.

Show comment
Hide comment
@sectioneight

sectioneight May 12, 2017

Sorry, what exactly do you mean by "the opposite"? Change dep or change go?

sectioneight commented May 12, 2017

Sorry, what exactly do you mean by "the opposite"? Change dep or change go?

@davecheney

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney May 12, 2017

Contributor
Contributor

davecheney commented May 12, 2017

@sectioneight

This comment has been minimized.

Show comment
Hide comment
@sectioneight

sectioneight May 12, 2017

Ok. In that case dep will fail if a dependency has a package named ".foo" since it doesn't see the source code.

Suggestions? Or am I missing something really obvious.

sectioneight commented May 12, 2017

Ok. In that case dep will fail if a dependency has a package named ".foo" since it doesn't see the source code.

Suggestions? Or am I missing something really obvious.

@davecheney

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney May 12, 2017

Contributor
Contributor

davecheney commented May 12, 2017

@sdboyer

This comment has been minimized.

Show comment
Hide comment
@sdboyer

sdboyer May 12, 2017

Member

(we can probably close this and discuss over in the dep issue)

Member

sdboyer commented May 12, 2017

(we can probably close this and discuss over in the dep issue)

@golang golang locked and limited conversation to collaborators May 12, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.