Some small naming issues

Note that this post is now out of date with respect to the particular filenames used in repository.

I’ve been working on the code generation in several areas and I’ve decided that I’m going to be consistent with names of things.

• As protobuf does, always use singular for a collection of things.
• Never use snake case in names or filenames. (Arrgh! Hugo expects filenames with underscores!)
• In filenames, dont use capitals because of filesystem differences. So a filename is more like compressed snake case than camel case.
• Versions are a pair (tuple of size 2) of (version name,variant). The current version is atlanta.base.
• Version names are cities with the first version being Atlanta. From there they will proceed alphabetically on the first letter, with the next version likely to Boradino.
• Variants are to deal with either supersets or subsets of the “base” code. Subsets are for restricted variants (like a “safe to run other people’s code” variant) and supersets are for non-standard features.
• Put the version in the path inside for all parigot code so that somebody who wants to can merge the “head” of the repo with some older version name or some other variant.
• Ignore three specific parts of the buf lint output that relate to names:
  • Services do not need to have the suffix “Service”. That’s just redundant.
  • Packages do not have to have the version number in the path. First, parigot itself uses the version scheme above. Second, for go developers, the use of the v1 suffix causes the go mapping of packages to directories to be nasty and you end up having to rename pretty much every import. I’ve set my directories up so that the last path component is “the one you want”.
  • Packages do not have to match the path for the input of protoc-based generators. In other words, you can cluster your “.proto” files together and configure the output directories of the protoc-based generators as appropriate. This makes the path names significantly shorter by cutting out a lot of empty directories. The proto directory, with this approach can and should be a first-level directory in your app’s workspace. The generated code will have lots of extra empty directories, but the autocompletion of any modern IDE makes that not a problem. For example, if you have a “.proto” file that declares its contents to be in package “foo.bar.baz”, the source code for this might be proto/mystuff.proto relative to your project root, but the generated code will be in proto/gen/foo/bar/baz/mystuff.p.go, or similar for other languages.
• Files that are generated by parigot tools have the suffix “.p.<normalsuffix>” as shown with the generated go code in example above.