3 ms·

> Probably there is no easy way out now they're past 1.0. Yeah, any attempt to change this would have to introduce something like a per-package pragma flag to

> Probably there is no easy way out now they're past 1.0. Yeah, any attempt to change this would have to introduce something like a per-package pragma flag to disallow nils. I feel they have painted themselves into a corner there. > Re GOPATH, what do you mean here? I mean that the "go" suite of build tools (build, get, install) rely on a specific convention: Your GOPATH is supposed to point to folders each containing bin, pkg and src subfolders with all packages. Let's say I am developing a package A that uses my own package B. Both on Github. You're supposed to then create: $GOPATH/src/A (which contains A's files as immediate children) and $GOPATH/src/B (ditto for B). The manuals I believe suggest that you have something ~/projects/go, under which you create bin/src/pkg and put your work. But I don't organize my home folder like that and I find it presumptuous that the tools assume that I do, so I have ~/.go, which contains bin/src/pkg, and I symlink stuff into ~/.go/src. Acceptable if annoying. > Re packages having one level - I actually love this I want to use folders as an organizing unit, the way they are intended. It makes sense even for small packages. Generic example (I have something very similar to this, but I don't want to go into details): I have a framework. There is a bunch of core interfaces, and then a bunch of implementations. Let's say that my interfaces are called Queue (with concrete implementations FooQueue, BarQueue, BazQueue etc.), Block (again, a bunch of concrete impls) and Stream (same). For my brain not go insane every time I look at my source tree, I want to have the core interfaces in the root, and then subfolders queues/, blocks/, streams/. That's not much to ask. Putting these things in separate packages with dependencies on the original package makes no sense, in particular because the original package has internal dependencies. For example, the framework has a configuration builder that connects queues, blocks and streams, and it knows certain things about the implementations and how they interconnect. Putting that into yet another package is just insanity. It's one package. And it needs subfolders. (Especially with how Go mandates that tests be in the same folder as the unit being tested!) I have encountered lots of C projects that pile all the files into a single root folder, instead of having a src/ folder with appropiate subfolders by category. I think that's what the Go guys are mimicking. I hate it. I mean, just the fact that a package needs the Go files to be in the root is pretty bad. I may have a docs/ there, a readme file, an examples/ folder, a locales/ folder -- why must the source files go in the root? They're not that special. I know you can import directly from a src, but the convention is 'import "github.com/foo/bar"', not "github.com/foo/bar/src"'. As I said, I don't want Java-style nested package names. All I want is to be able to organize the files. After all, the location of the files doesn't matter to the compiler. (Java used to be like this at one point, too, unsure if it's still the case: What you put in the package decl didn't need to match up with the structure of your folders.) > Re the versioning, they originally resisted versioning the language ... Hope this will be solved. I suggest something similar to Ruby's Bundler -- don't make it part of the language, but part of the development environment. > ... as this is the stort of thing I hate even in the limited version they have Agree, I would rather see no tagging at all, rather than the flimsy stuff they have today.

grey-area 14y ago
Re package paths, I guess the tradeoff here is for go get/install etc to be able to include or fetch dependencies, it needs to know where to put them and install them, and this was the simplest system they could think of which worked. Nowadays I think it's ~/.go/src/github.com/user/pkg rather than just ~/.go/src/pkg It would be nice to be able to specify goinstall and golib paths or something though, and I guess your symlinked idea is a good workaround. I have just gone with the flow on this one, and don't mind as don't have gopath at the root of ~/. Re folders versus sub-packages, yes I take your point - again there are some conventions here they've tried to impose to make it simpler for the package tools, but those could get in the way. I also hate projects that have all the files piled into one dir, so I prefer to break into sub-modules where possible and make the organisation clear. The other advantage of this is that people could use just your sub-module if they want. I've developed a few packages which I wanted subfolders for, but those subfolders naturally became sub-packages without much wrangling - seeing too many files on one level forced me to organise them and create more packages. One case for example mirrors your usage - a top level pkg, with interfaces and concrete types for specific databases, which lived in their own folder 'adapters' this became a sub-package, which contained the interface and concrete implementations, and it being a package forced me to remove any knowledge of the enclosing package and any circular refs - the top level pkg knows about the adapters, but adapters don't know about the top level. I felt like this was making the code better, not worse, by removing internal dependencies, but YMMV, and I can see how it would be annoying. I'm willing to forgive conventions like this if the tradeoff feels worth it (in this case I really like the go gettable packages, and to have that am willing to live with restrictions like some code must be in root, folder=subpackage, etc.).
- lobster_johnson 14y ago
  With the subpackage, did you actually put the stuff in subfolders of the original package, or did they have two different top-level folder names? In other words, was it import ( "github.com/foo/x-core" "github.com/foo/x-adapters" ) or import ( "github.com/foo/x" "github.com/foo/x/adapters" ) If the second, then do you need to do something special with regards to compilation or anything else? One thing that bugs me with the second approach is that the package names then have to be different. If the original core package is called "x", and you have an "adapters" package, would the package name be something like "x_adapters"? Just "adapters" seems a bit presumptuous (it's very generic).

grey-area 14y ago

Re package paths, I guess the tradeoff here is for go get/install etc to be able to include or fetch dependencies, it needs to know where to put them and install them, and this was the simplest system they could think of which worked. Nowadays I think it's ~/.go/src/github.com/user/pkg rather than just ~/.go/src/pkg It would be nice to be able to specify goinstall and golib paths or something though, and I guess your symlinked idea is a good workaround. I have just gone with the flow on this one, and don't mind as don't have gopath at the root of ~/. Re folders versus sub-packages, yes I take your point - again there are some conventions here they've tried to impose to make it simpler for the package tools, but those could get in the way. I also hate projects that have all the files piled into one dir, so I prefer to break into sub-modules where possible and make the organisation clear. The other advantage of this is that people could use just your sub-module if they want. I've developed a few packages which I wanted subfolders for, but those subfolders naturally became sub-packages without much wrangling - seeing too many files on one level forced me to organise them and create more packages. One case for example mirrors your usage - a top level pkg, with interfaces and concrete types for specific databases, which lived in their own folder 'adapters' this became a sub-package, which contained the interface and concrete implementations, and it being a package forced me to remove any knowledge of the enclosing package and any circular refs - the top level pkg knows about the adapters, but adapters don't know about the top level. I felt like this was making the code better, not worse, by removing internal dependencies, but YMMV, and I can see how it would be annoying. I'm willing to forgive conventions like this if the tradeoff feels worth it (in this case I really like the go gettable packages, and to have that am willing to live with restrictions like some code must be in root, folder=subpackage, etc.).

lobster_johnson 14y ago
With the subpackage, did you actually put the stuff in subfolders of the original package, or did they have two different top-level folder names? In other words, was it import ( "github.com/foo/x-core" "github.com/foo/x-adapters" ) or import ( "github.com/foo/x" "github.com/foo/x/adapters" ) If the second, then do you need to do something special with regards to compilation or anything else? One thing that bugs me with the second approach is that the package names then have to be different. If the original core package is called "x", and you have an "adapters" package, would the package name be something like "x_adapters"? Just "adapters" seems a bit presumptuous (it's very generic).