opensource.google.com

Menu

Docs

Put the Code in (the Right) //third_party

go/thirdparty/where

Find the right //third_party

Most third-party code lives in //piper/third_party. 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/.../ThirdParty
Older deprecated location for iOS Third Party code.
//piper/.../ThirdParty
Old location for mac applications. See go/thirdpartygooglemac.
//piper/.../third_party
old location (readonly, historical)
//piper/.../third_party
Special repository for packages of third-party applications.

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/.../....

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 sub directories

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 sub directory. 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 sub directory is for and link to the above emailremoved@ thread
  • OWNERS files may not exist above the individual package level (the directory which contains a METADATA file with a third_party field). You may not have an OWNERS file in the sub directory itself. 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 sub directory 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/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.