#Yet Another Packaging Question

42 messages · Page 1 of 1 (latest)

rapid oak
#

So I am starting a new project, and we are using a private repository with protected branches etc (so I can't just commit to master) - my original ideal structure was something like this:

/api
  /cmd
    /server
      main.go
/negotiator
  negotiator.go
go.mod

I started working with a very minimal "exported" struct like so:

## /negotiator/negotiator.go
package negotiator
struct Test {}

and then importing it like this:

## /api/cmd/server/main.go
import (
  "fmt";
  "gitlab.myorg.whatever/repo-name/negotiator
)

Which it can't find, because that code is not on main yet, but I also am not allowed to do something like:

## /api/cmd/server/main.go
import (
  "fmt";
  "negotiator";
)

What is the right way to do such a structure?

still thistle
#

Which it can't find, because that code is not on main yet
if what you've presented is correct, you're misinterpreting what's going on. code imported from the same module does not have versioning applied to it, it simply uses the code as-is (the module is versioned as a whole, not as individual packages)

#

you're sure that this is all in one module, and that the module name listed in go.mod matches the root of the negotiator package path?

lunar wolf
#

also you don't need api/cmd/ unless you plan to have dozens of binaries in some sort of mono repo with more than 1 category

rapid oak
#

I mean, it's possible that I messed this up with an init, but at present there is only one go.mod in my repository.

still thistle
#

okay, cool. is the name of your module gitlab.myorg.whatever/repo-name?

lunar wolf
#

but you would need to use the module name ^

still thistle
#

(obviously that's a placeholder)

lunar wolf
#

whichever is in go.mod first line, as a prefix to all other packages in that repo

rapid oak
#

Let me reverify , the answer is "I think so", but I am notably deficient in "eyes"

#

Ok, so I have, having at one point thought moving these files into direct subdirs might help,

repo-root-folder
    /api
        /foo
            negotiator.go
        /server
            main.go

My module is
module gitlab.myorg.com/org/teams/myteam/repo-root-folder
And I am importing as
gitlab.myorg.com/org/teams/myteam/repo-root-folder/api/foo/negotiator

lunar wolf
#

missing repo-root-folder

rapid oak
#

Let me double check to make sure I didn't just mistype that on phone

lunar wolf
#

also negotiator is not a package

rapid oak
#

It was there

lunar wolf
#

in your last tree that is

rapid oak
#

negotiator.go contains a package declaration, what else do I have to do?

lunar wolf
#

packages are directories not files

still thistle
#

come from python? 😆

rapid oak
#

And Rust

still thistle
#

i can't comment on rust, but yeah things are definitely different than python

#

like _dl said, packages are always entire directories, not individual files

#

conventionally, your package name should match the name of the directory it's in

#

this technically doesn't have to be the case but things get really confusing if they don't

rapid oak
#

Ah, ok, interesting, so unlike Java and C# land as well!

lunar wolf
#

well java is also like that just that they restart at « com » while go splits the module root from the directories

rapid oak
#

Well, at least in C# the manager takes the packages/module directions internal to the files as writ of law

still thistle
#

files are essentially meaningless to the Go compiler, just keep that in mind as you go

#

the core unit of organization from the compiler level is the package

#

obviously files can help humans organize things but they don't mean anything from a technical perspective

rapid oak
#

Right that makes sense at a compiler level, I was just having trouble modeling what actually made a "package" happen

lunar wolf
#

having any number of files in a directory that all have the same package line at the top

rapid oak
#

Ok, so if I have two files with different package directives in the same directory, I'm assuming that doesn't work (not that I would do that, or at least I haven't seen a need yet to want to)

lunar wolf
#

and the compiler will complain if that’s not the case (mismatch in package names)

rapid oak
#

Well thank you all that was a very concise explanation , I will continue on - but I expect to have skissues in the future and promise to do as much due diligence as I can before I ask again

lunar wolf
#

do keep it simple/fewer directories - imo

#

you might find the end of ^ relevant

rapid oak
#

That is actually super helpful and practical advice, and meets the nice middleground of developers who have programmed computer before but are new to the ecosystem. I'm just happy I get to use static types like I can in Rust now - at work!

#

(Most of my dev is in python becuase most of my dev tends towards the "scrappy" end )

lunar wolf
#

at least be happy they aren't node.js folks 🙂

#

and thx!