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.
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 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 very 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.md
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 aMETADATA
file with athird_party
field) to bypass emailremoved@ review. TheOWNERS
file of the subdirectory itself should only containper-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.