import a file

[jules]

I'm new to golang and learning it in evenings with no one to ask questions of.   I have a local files:

Here is  /home/jules/go/src/jsonstuff/typestuff.go :

package jsonstuff

type Prices struct {
    BidPrice float64 `json:"p"`
}

--------------------------------------------------------

Here is /home/jules/go/sampleproject/main.go

package main

import (
        "fmt"
        "jsonstuff"
)

func main() {
        var price Prices
        fmt.Println("Hello golang")
        fmt.Println(price)
}
=====================================

But I get the error:

~/go/sampleproject$ go run main.go
# command-line-arguments
./main.go:5:2: imported and not used: "jsonstuff"
./main.go:13:12: undefined: Prices

Why is it not picking up the type from the import file?

[Kurtis Rader]

See https://golang.org/ref/spec#Import_declarations. By default importing a package requires using the package name to refer to any symbols it exports; e.g., "jsonstuff.Prices". You can do "import . jsonstuff" to allow accessing its public symbols without qualification. Google "go import unqualified" for some discussions about the pros and cons of unqualified imports.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a3bdeaae-19b4-4a31-ad56-b5afe54d2185o%40googlegroups.com.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[jake...@gmail.com]

On Tuesday, July 28, 2020 at 11:21:38 PM UTC-4 Kurtis Rader wrote:

See https://golang.org/ref/spec#Import_declarations. By default importing a package requires using the package name to refer to any symbols it exports; e.g., "jsonstuff.Prices". You can do "import . jsonstuff" to allow accessing its public symbols without qualification. Google "go import unqualified" for some discussions about the pros and cons of unqualified imports.

As a beginner, please don't use the "." imports. It is very non-standard and bad form in all but a few specific cases.  Start good habits early. The correct eay to reference prices is "jsonstuff.Prices"

[jules]

Thanks Kurtis and Jake.  Adding jsonstuff.Prices fixed it.

I have a second question related to weird behavior of using modules:

-------------------------------------------------------

$ go run main.go
Hello golang
{0}
$ go env | egrep PATH
GOPATH="/home/jfields/go"

$ rm go.mod
$ go mod init src
go: creating new go.mod: module src
$ more go.mod
module src

go 1.14
$ go run main.go
main.go:7:2: package jsonstuff is not in GOROOT (/usr/local/go/src/jsonstuff)

$ ls  /home/jfields/go/src/jsonstuff
typestuff.go

$ rm go.mod
$ go run main.go
Hello golang
{0}
-----------------------------------------------------------

I read somewhere we are supposed to use modules now.  When tried making a go.mod file,  program failed to find package jsonstuff?

Had to delete go.mod to get it to compile?

Sorry, another newbie question.

[Volker Dobler]

The best advice is: Read How to Write Go Code

https://golang.org/doc/code.html

and stick to it.

Yes, modules are the thing to be used

1. But naming a module "src" is begging for trouble.

Name your module either something like

  julesgocode.org/firsttry

or maybe

  github.com/<yourgithubnamehere>/firsttry

2. If your package jsonstuff lifes in module

"julesgocode.org/firsttry" then its import path

is "julesgocode.org/firsttry/jsonstuff".

One thing a lot of Go newcomers seem to  have trouble

with is the fact that the go tool works best on packages

and _not_ on files: You dop not import files and you do

not run files and you do not test files. Files contain the

sources but are basically uninteresting: Focus on

packages (and modules). Packages life in modules.

Modules have a _sensible_ name or might even point

directly to your revision control system. Packages

are named like the filesystem folder the are contained.

Importing happens by "full qualified import  path", i.e.

   <full-name-of-module>/<relative-FS-path-inside-module>

This is not the whole truth but the basic essence of how

you should work.

V. 

[Jesper Louis Andersen]

On Thu, Jul 30, 2020 at 12:54 PM Volker Dobler <dr.volke...@gmail.com> wrote:

You dop not import files and you do

not run files and you do not test files. Files contain the

sources but are basically uninteresting: Focus on

packages (and modules). 

In Go, we disconnect the name of a file and the package in which it lives. That is, the programmer is free (mostly) to choose whatever names for files in a package, and also free to create as many files as is seen necessary. It is in contrast to a large set of other languages, which require that the package and the filename stay the same. The advantage is that you can have very large packages and gracefully split them over multiple files without having to resort to inventing new internal package names.

My general view is that you shouldn't assume a connection between the file system and the packages of your language, and the languages which do have the wrong design. However, since that "mistake" is made in many languages, people tend to get somewhat confused when they encounter a system where it isn't the case.

[Julian Fields]

Thanks Jesper and Volker.

After reading the article(s) and go help modules and a few blogs, I still was not able to see why deleting go.mod makes the program import

jsonstuff package, and compile and run?

Modules are a great idea and I want to use them, but I can't get it to compile

a "hello golang" program even:

=======================

$ ls  /home/jfields/go/src/jsonstuff
typestuff.go
$ go mod init src
go: creating new go.mod: module src
$ more go.mod
module src

go 1.14
$ go run main.go
main.go:7:2: package jsonstuff is not in GOROOT (/usr/local/go/src/jsonstuff)
$ rm go.mod
$ go run main.go
Hello golang
{0}

=========================

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/pP-0WEpzbEs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiX%2BN%2BospARM7adQ1E0wk-K7M73Jbj1KEUXkxjGGq9Q9zg%40mail.gmail.com.

[Nathan Fisher]

Hola!

Based on your initial project layout you have a couple of issues. When using the legacy gopath everything should ideally live under that path. Imports then become relative to that root.

Your main lives outside of the root which works with go run but is not how a project should be structured.

For a small toy project I would place both files in the same directory and set their package name to main.

If however your objective is to better understand imports then I would reconsider your project structure. In the root directory of your project I would place your main.go and run “go mod init” there. In that root directory you can then create your jsonstuff directory. As an example:

project/main.go

project/go.mod

project/jsonstuff/types.go

When using go mod it typically (but not always) maps to a single module/project/repository.

go mod init <module>

The module specified above is usually a URI without the protocol. By following this practise it makes the project “go gettable”. If you maintain src as your module name you would need to change the import for jsonstuff to src/jsonstuff and move your main.go to the src directory.

As mentioned by others src isn’t a good name for a module. Better to do something like:

go mod init github.com/<your account>/helloworld

You would then change your jsonstuff import to:

github.com/<your account>/helloworld/jsonstuff

Be aware only one package can live per directory except the special *_test form which restricts test access to the packages public api only.

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAAcmRO8TZ4ftK%2BFsTQTw7nEGZ0e3gFFpv5uygb4S6YavVRe_Xg%40mail.gmail.com.

--

Nathan Fisher

 w: http://junctionbox.ca/

[Volker Dobler]

On Friday, 31 July 2020 04:55:50 UTC+2, jules wrote:

Modules are a great idea and I want to use them, but I can't get it to compile

a "hello golang" program even:

=======================

$ ls  /home/jfields/go/src/jsonstuff
typestuff.go
$ go mod init src
go: creating new go.mod: module src
$ more go.mod
module src

go 1.14
$ go run main.go
main.go:7:2: package jsonstuff is not in GOROOT (/usr/local/go/src/jsonstuff)
$ rm go.mod
$ go run main.go
Hello golang
{0}

=========================

Once again:

1. Naming the module "src" is _wrong_.

Do _not_ do this! Use "myfirst.project".

 

2. Do nut use go run. Use go build.

(or at least, if there are  _fundamental_ issues

which prevent you from typing  `go build` at

least use `go run .`.

3. Now that your module is called "myfirst.project"

the import path of package jsonstuff in main.go

_must_ read

   import "myfirst.project/jsonstuff"

You _must_ name your module properly and

you _must_ use the proper import path. You code

as is is _invalid_ and _cannot_ be compiled.

You must follow the rules.

You should delete everything  and start afresh

in the way described by How To Write Go Code.

V.