Docs

Put the Code in (the Right) //third_party

Find the right //third_party

Most third-party code lives in //piper/third_party. If you are not on Piper, please see go/thirdparty/non-google3. But because we have separate locations for third-party code, as enumerated in the expanding list of all //third_party locations below. If you can’t find an appropriate //third_party, email emailremoved@ and we’ll help you find one. Do NOT create your own project-specific //third_party repository without approval from emailremoved@. Put packages in one of these locations instead.

NOTE: With the exception of Java and Haskell, you should put your code straight into the package directory, not in a versioned subdirectory. That is, straight into, e.g., //piper/.../... and not into //piper/.../....

Approved `//third_party` code locations

//piper/.../third_party: This is the main //third_party respository, used by anything that builds with google3.
//piper/.../third_party: Special repository for production/monitoring.
//piper/.../third_party: Wireless applications (Blackberry, J2ME, etc.) that don’t build against //google3. This replaces //piper/.../third_party.
//piper/.../vendor_src and //piper/.../google_vendor_src_branch: Code not built by blaze (such as standalone binaries and .rpm packages), that does not fall into any of the above categories, probably needs to use the go/vendorsrc method.

Platforms open source locations

//piper/.../patched_vendor_src: Packages used by non-google3 go/platforms-networking code; a variation on the go/vendorsrc method.
//piper/.../patched_vendor_src: Packages used by non-google3 platforms networking hardware go/planethw code; a variation on the go/vendorsrc method.

Finance depot open source locations

//piper/.../third_party: Third party code used in //piper/…/finance applications

Client open source locations

//piper/.../third_party: Third party respository specifically for the go/analytics client application, which is not built against google3.

Deprecated / deleted

//piper/.../third_party: An older, deprecated location for third-party “data”.
//piper/.../third_party: Old location for client code. See go/thirdpartygoogleclient.
//piper/.../third_party: old location (readonly, historical)
//piper/.../third_party: Special repository for packages of third-party applications.

Separate out dependencies

Many open source projects include all of their dependencies. This is prone to introducing versioning problems. Therefore we require that you strip out dependencies from code you import. These dependencies can be replaced by dependencies to other code in //third_party. There’s a high probability that the depended-upon libraries are already in //third_party.

Dependencies for open source/MOE builds

If you’re adding libraries used by open source builds in blaze rather than by Google-internal code (for example, you have an MOE project or other open source code subset with an sh_test verifying it builds in ant or maven), then put them in //piper/third_party/moe_support. See ThirdPartyMoeSupport for full instructions.

//third_party subdirectories

Most of the time, new third-party packages should go in the appropriate language-specific directory, or in a new top-level directory. On rare occasions, there might be need to group packages under a subdirectory. For example, //piper/third_party/apphosting exists because of the unique way in which App Engine uses third-party libraries. In these cases, the following rules must be observed:

Email emailremoved@ first to discuss your use case and get it approved
Include a README.txt file that explains what the subdirectory is for and link to the above emailremoved@ thread
The OWNERS file for the subdirectory, if present, must not permit addition of new directories above the individual package level (the directory which contains a METADATA file with a third_party field) to bypass emailremoved@ review. The OWNERS file of the subdirectory itself should only contain per-file directives. This is to ensure that all new packages go through compliance review.

Packages in //third_party/golang will sometimes be grouped under a common directory to reflect upstream grouping. This is fine, provided that the rule about OWNERS file above is still observed.

If packages in the subdirectory will be managed by the same people, it is common to have an OWNERS.team file in the root directory which contains the package maintainers. Then each package’s OWNERS file contains a line to include the OWNERS.team file. For example:

//third_party/foo/OWNERS.foo:

googler1
googler2

//third_party/foo/OWNERS:

per-file OWNERS.foo=file:OWNERS.foo

//third_party/foo/package/OWNERS:

file:../OWNERS.foo

TIP: The file directive in OWNERS files in //third_party should point to OWNERS files also within //third_party. Otherwise, Googlers who never touch third-party code may be considered “owners” of third-party code, much to their surprise.

NEXT: Get the code to work with Google

Except as otherwise noted, the content of this page is licensed under CC-BY-4.0 license. Third-party product names and logos may be the trademarks of their respective owners.