You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
depot_tools/support/chromite_wrapper

97 lines
3.0 KiB
Plaintext

Cleanup chromite_wrapper. The original design of this had some issues: 1) forced targets to be importable via 'buildbot.cbuildbot', rather than the proper/full 'chromite.buildbot.cbuildbot'. Scripts worked around this, but it's an unwanted limitation. 2) That importation requirement means that within the chroot, we've had to export cros_sdk *and* cros_sdk.py in the PATH. This is undesirable clutter, and introduces potential errors as scripts localize themselves to cros_sdk.py rather than invoking cros_sdk (the consumers should be agnostic to the language the tool is written in). 3) chromite_wrapper enforced assumptions about python namespace w/in the targets- specifically that 'main' must always be invokable without any arguments. This limits refactoring/cleanup in chromite via having to support ancient API assumptions (api's that weren't public); modern chromite has repurposed main changing the prototype, and using it's own wrapper doing signal handler setup, and general framework behaviour. Longer term, that 'main' functor is unlikely to even exist. The strong coupling chromite_wrapper forced limits are refactoring possibilities. 4) In modern chromite, all user consumable tools are now required to exist w/in chromite/bin/, and be executable and invokable. This is what we want going forward. 5) Implied we want chromite_wrapper used w/in the chroot; we don't, thus drop all CROS_WORKON_SRCROOT awareness. 6) Exposed a chromite_wrapper invokable (that didn't work) into the PATH outside the chroot; this is resolved via moving it into a support directory and repointing symlinks to it. At this point, if it's working with a modern chromite checkout the script is a simple execv pass thru. If it isn't, then it will fallback to the old import trickery. This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*, basically all branches w/in chromite without issue. git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98
13 years ago
#!/usr/bin/env python
# Copyright (c) 2011 The Chromium OS Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
"""Wrapper for chromite tools.
The script is intend to be symlinked to any number of chromite tools, attempts
to find the path for chromite, and hands off to the right tool via exec if
possible.
It is intended to used strictly outside of the chroot.
If you're looking at a copy and want to know where the original looks at, look
here:
http://git.chromium.org/gitweb/?p=chromite.git;a=blob;f=bin/chromite
Since this script is _copied_, it should remain small and not use internal libs.
"""
import errno
import os
import sys
# Due to historical reasons, and the fact depot_tools ToT is used by older
# factory branches (lacking chromite script cleanups), note we have to
# fallback to some odd import locations. This is the only reason for the
# fallback code- any/all new scripts symlinked to this script *must* exist
# in chromite/bin/ .
def _FindChromite(path):
"""Find the chromite dir in a repo, gclient, or submodule checkout."""
Cleanup chromite_wrapper. The original design of this had some issues: 1) forced targets to be importable via 'buildbot.cbuildbot', rather than the proper/full 'chromite.buildbot.cbuildbot'. Scripts worked around this, but it's an unwanted limitation. 2) That importation requirement means that within the chroot, we've had to export cros_sdk *and* cros_sdk.py in the PATH. This is undesirable clutter, and introduces potential errors as scripts localize themselves to cros_sdk.py rather than invoking cros_sdk (the consumers should be agnostic to the language the tool is written in). 3) chromite_wrapper enforced assumptions about python namespace w/in the targets- specifically that 'main' must always be invokable without any arguments. This limits refactoring/cleanup in chromite via having to support ancient API assumptions (api's that weren't public); modern chromite has repurposed main changing the prototype, and using it's own wrapper doing signal handler setup, and general framework behaviour. Longer term, that 'main' functor is unlikely to even exist. The strong coupling chromite_wrapper forced limits are refactoring possibilities. 4) In modern chromite, all user consumable tools are now required to exist w/in chromite/bin/, and be executable and invokable. This is what we want going forward. 5) Implied we want chromite_wrapper used w/in the chroot; we don't, thus drop all CROS_WORKON_SRCROOT awareness. 6) Exposed a chromite_wrapper invokable (that didn't work) into the PATH outside the chroot; this is resolved via moving it into a support directory and repointing symlinks to it. At this point, if it's working with a modern chromite checkout the script is a simple execv pass thru. If it isn't, then it will fallback to the old import trickery. This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*, basically all branches w/in chromite without issue. git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98
13 years ago
path = os.path.abspath(path)
# Depending on the checkout type (whether repo chromeos or gclient chrome)
# Chromite lives in a different location.
roots = (
('.repo', 'chromite/.git'),
('.gclient', 'src/third_party/chromite/.git'),
('src/.gitmodules', 'src/third_party/chromite/.git'),
)
Cleanup chromite_wrapper. The original design of this had some issues: 1) forced targets to be importable via 'buildbot.cbuildbot', rather than the proper/full 'chromite.buildbot.cbuildbot'. Scripts worked around this, but it's an unwanted limitation. 2) That importation requirement means that within the chroot, we've had to export cros_sdk *and* cros_sdk.py in the PATH. This is undesirable clutter, and introduces potential errors as scripts localize themselves to cros_sdk.py rather than invoking cros_sdk (the consumers should be agnostic to the language the tool is written in). 3) chromite_wrapper enforced assumptions about python namespace w/in the targets- specifically that 'main' must always be invokable without any arguments. This limits refactoring/cleanup in chromite via having to support ancient API assumptions (api's that weren't public); modern chromite has repurposed main changing the prototype, and using it's own wrapper doing signal handler setup, and general framework behaviour. Longer term, that 'main' functor is unlikely to even exist. The strong coupling chromite_wrapper forced limits are refactoring possibilities. 4) In modern chromite, all user consumable tools are now required to exist w/in chromite/bin/, and be executable and invokable. This is what we want going forward. 5) Implied we want chromite_wrapper used w/in the chroot; we don't, thus drop all CROS_WORKON_SRCROOT awareness. 6) Exposed a chromite_wrapper invokable (that didn't work) into the PATH outside the chroot; this is resolved via moving it into a support directory and repointing symlinks to it. At this point, if it's working with a modern chromite checkout the script is a simple execv pass thru. If it isn't, then it will fallback to the old import trickery. This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*, basically all branches w/in chromite without issue. git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98
13 years ago
while path != '/':
for root, chromite_git_dir in roots:
if all(os.path.exists(os.path.join(path, x))
for x in [root, chromite_git_dir]):
return os.path.dirname(os.path.join(path, chromite_git_dir))
Cleanup chromite_wrapper. The original design of this had some issues: 1) forced targets to be importable via 'buildbot.cbuildbot', rather than the proper/full 'chromite.buildbot.cbuildbot'. Scripts worked around this, but it's an unwanted limitation. 2) That importation requirement means that within the chroot, we've had to export cros_sdk *and* cros_sdk.py in the PATH. This is undesirable clutter, and introduces potential errors as scripts localize themselves to cros_sdk.py rather than invoking cros_sdk (the consumers should be agnostic to the language the tool is written in). 3) chromite_wrapper enforced assumptions about python namespace w/in the targets- specifically that 'main' must always be invokable without any arguments. This limits refactoring/cleanup in chromite via having to support ancient API assumptions (api's that weren't public); modern chromite has repurposed main changing the prototype, and using it's own wrapper doing signal handler setup, and general framework behaviour. Longer term, that 'main' functor is unlikely to even exist. The strong coupling chromite_wrapper forced limits are refactoring possibilities. 4) In modern chromite, all user consumable tools are now required to exist w/in chromite/bin/, and be executable and invokable. This is what we want going forward. 5) Implied we want chromite_wrapper used w/in the chroot; we don't, thus drop all CROS_WORKON_SRCROOT awareness. 6) Exposed a chromite_wrapper invokable (that didn't work) into the PATH outside the chroot; this is resolved via moving it into a support directory and repointing symlinks to it. At this point, if it's working with a modern chromite checkout the script is a simple execv pass thru. If it isn't, then it will fallback to the old import trickery. This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*, basically all branches w/in chromite without issue. git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98
13 years ago
path = os.path.dirname(path)
return None
def _MissingErrorOut(target):
sys.stderr.write(
"""ERROR: Couldn't find the chromite tool %s.
Please change to a directory inside your Chromium OS source tree
and retry. If you need to setup a Chromium OS source tree, see
http://www.chromium.org/chromium-os/developer-guide
""" % target)
return 127
def main():
chromite_dir = _FindChromite(os.getcwd())
Cleanup chromite_wrapper. The original design of this had some issues: 1) forced targets to be importable via 'buildbot.cbuildbot', rather than the proper/full 'chromite.buildbot.cbuildbot'. Scripts worked around this, but it's an unwanted limitation. 2) That importation requirement means that within the chroot, we've had to export cros_sdk *and* cros_sdk.py in the PATH. This is undesirable clutter, and introduces potential errors as scripts localize themselves to cros_sdk.py rather than invoking cros_sdk (the consumers should be agnostic to the language the tool is written in). 3) chromite_wrapper enforced assumptions about python namespace w/in the targets- specifically that 'main' must always be invokable without any arguments. This limits refactoring/cleanup in chromite via having to support ancient API assumptions (api's that weren't public); modern chromite has repurposed main changing the prototype, and using it's own wrapper doing signal handler setup, and general framework behaviour. Longer term, that 'main' functor is unlikely to even exist. The strong coupling chromite_wrapper forced limits are refactoring possibilities. 4) In modern chromite, all user consumable tools are now required to exist w/in chromite/bin/, and be executable and invokable. This is what we want going forward. 5) Implied we want chromite_wrapper used w/in the chroot; we don't, thus drop all CROS_WORKON_SRCROOT awareness. 6) Exposed a chromite_wrapper invokable (that didn't work) into the PATH outside the chroot; this is resolved via moving it into a support directory and repointing symlinks to it. At this point, if it's working with a modern chromite checkout the script is a simple execv pass thru. If it isn't, then it will fallback to the old import trickery. This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*, basically all branches w/in chromite without issue. git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98
13 years ago
target = os.path.basename(sys.argv[0])
if chromite_dir is None:
Cleanup chromite_wrapper. The original design of this had some issues: 1) forced targets to be importable via 'buildbot.cbuildbot', rather than the proper/full 'chromite.buildbot.cbuildbot'. Scripts worked around this, but it's an unwanted limitation. 2) That importation requirement means that within the chroot, we've had to export cros_sdk *and* cros_sdk.py in the PATH. This is undesirable clutter, and introduces potential errors as scripts localize themselves to cros_sdk.py rather than invoking cros_sdk (the consumers should be agnostic to the language the tool is written in). 3) chromite_wrapper enforced assumptions about python namespace w/in the targets- specifically that 'main' must always be invokable without any arguments. This limits refactoring/cleanup in chromite via having to support ancient API assumptions (api's that weren't public); modern chromite has repurposed main changing the prototype, and using it's own wrapper doing signal handler setup, and general framework behaviour. Longer term, that 'main' functor is unlikely to even exist. The strong coupling chromite_wrapper forced limits are refactoring possibilities. 4) In modern chromite, all user consumable tools are now required to exist w/in chromite/bin/, and be executable and invokable. This is what we want going forward. 5) Implied we want chromite_wrapper used w/in the chroot; we don't, thus drop all CROS_WORKON_SRCROOT awareness. 6) Exposed a chromite_wrapper invokable (that didn't work) into the PATH outside the chroot; this is resolved via moving it into a support directory and repointing symlinks to it. At this point, if it's working with a modern chromite checkout the script is a simple execv pass thru. If it isn't, then it will fallback to the old import trickery. This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*, basically all branches w/in chromite without issue. git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98
13 years ago
return _MissingErrorOut(target)
path = os.path.join(chromite_dir, 'bin', target)
Cleanup chromite_wrapper. The original design of this had some issues: 1) forced targets to be importable via 'buildbot.cbuildbot', rather than the proper/full 'chromite.buildbot.cbuildbot'. Scripts worked around this, but it's an unwanted limitation. 2) That importation requirement means that within the chroot, we've had to export cros_sdk *and* cros_sdk.py in the PATH. This is undesirable clutter, and introduces potential errors as scripts localize themselves to cros_sdk.py rather than invoking cros_sdk (the consumers should be agnostic to the language the tool is written in). 3) chromite_wrapper enforced assumptions about python namespace w/in the targets- specifically that 'main' must always be invokable without any arguments. This limits refactoring/cleanup in chromite via having to support ancient API assumptions (api's that weren't public); modern chromite has repurposed main changing the prototype, and using it's own wrapper doing signal handler setup, and general framework behaviour. Longer term, that 'main' functor is unlikely to even exist. The strong coupling chromite_wrapper forced limits are refactoring possibilities. 4) In modern chromite, all user consumable tools are now required to exist w/in chromite/bin/, and be executable and invokable. This is what we want going forward. 5) Implied we want chromite_wrapper used w/in the chroot; we don't, thus drop all CROS_WORKON_SRCROOT awareness. 6) Exposed a chromite_wrapper invokable (that didn't work) into the PATH outside the chroot; this is resolved via moving it into a support directory and repointing symlinks to it. At this point, if it's working with a modern chromite checkout the script is a simple execv pass thru. If it isn't, then it will fallback to the old import trickery. This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*, basically all branches w/in chromite without issue. git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98
13 years ago
try:
os.execv(path, [path] + sys.argv[1:])
except EnvironmentError, e:
if e.errno not in (errno.ENOENT, errno.EPERM):
raise
# Reaching here means it's either a bad target, or we're working against
# an old (pre 6be2efcf5bb575b03862113eec097c44d8d7f93e) revision of
# chromite. Fallback to trying to import it; this code works at least as
# far back as branch 0.11.241.B; likely further.
Cleanup chromite_wrapper. The original design of this had some issues: 1) forced targets to be importable via 'buildbot.cbuildbot', rather than the proper/full 'chromite.buildbot.cbuildbot'. Scripts worked around this, but it's an unwanted limitation. 2) That importation requirement means that within the chroot, we've had to export cros_sdk *and* cros_sdk.py in the PATH. This is undesirable clutter, and introduces potential errors as scripts localize themselves to cros_sdk.py rather than invoking cros_sdk (the consumers should be agnostic to the language the tool is written in). 3) chromite_wrapper enforced assumptions about python namespace w/in the targets- specifically that 'main' must always be invokable without any arguments. This limits refactoring/cleanup in chromite via having to support ancient API assumptions (api's that weren't public); modern chromite has repurposed main changing the prototype, and using it's own wrapper doing signal handler setup, and general framework behaviour. Longer term, that 'main' functor is unlikely to even exist. The strong coupling chromite_wrapper forced limits are refactoring possibilities. 4) In modern chromite, all user consumable tools are now required to exist w/in chromite/bin/, and be executable and invokable. This is what we want going forward. 5) Implied we want chromite_wrapper used w/in the chroot; we don't, thus drop all CROS_WORKON_SRCROOT awareness. 6) Exposed a chromite_wrapper invokable (that didn't work) into the PATH outside the chroot; this is resolved via moving it into a support directory and repointing symlinks to it. At this point, if it's working with a modern chromite checkout the script is a simple execv pass thru. If it isn't, then it will fallback to the old import trickery. This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*, basically all branches w/in chromite without issue. git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98
13 years ago
if target == 'cbuildbot':
target = 'chromite.buildbot.cbuildbot'
else:
target = 'chromite.bin.%s' % (target,)
# Adjust the path importation so we can import our our target.
sys.path.insert(0, os.path.dirname(chromite_dir))
Cleanup chromite_wrapper. The original design of this had some issues: 1) forced targets to be importable via 'buildbot.cbuildbot', rather than the proper/full 'chromite.buildbot.cbuildbot'. Scripts worked around this, but it's an unwanted limitation. 2) That importation requirement means that within the chroot, we've had to export cros_sdk *and* cros_sdk.py in the PATH. This is undesirable clutter, and introduces potential errors as scripts localize themselves to cros_sdk.py rather than invoking cros_sdk (the consumers should be agnostic to the language the tool is written in). 3) chromite_wrapper enforced assumptions about python namespace w/in the targets- specifically that 'main' must always be invokable without any arguments. This limits refactoring/cleanup in chromite via having to support ancient API assumptions (api's that weren't public); modern chromite has repurposed main changing the prototype, and using it's own wrapper doing signal handler setup, and general framework behaviour. Longer term, that 'main' functor is unlikely to even exist. The strong coupling chromite_wrapper forced limits are refactoring possibilities. 4) In modern chromite, all user consumable tools are now required to exist w/in chromite/bin/, and be executable and invokable. This is what we want going forward. 5) Implied we want chromite_wrapper used w/in the chroot; we don't, thus drop all CROS_WORKON_SRCROOT awareness. 6) Exposed a chromite_wrapper invokable (that didn't work) into the PATH outside the chroot; this is resolved via moving it into a support directory and repointing symlinks to it. At this point, if it's working with a modern chromite checkout the script is a simple execv pass thru. If it isn't, then it will fallback to the old import trickery. This has been tested against R16, R17, R18, ToT, 0.11.241.B, factory-*, basically all branches w/in chromite without issue. git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@128555 0039d316-1c4b-4281-b951-d872f2087c98
13 years ago
try:
module = __import__(target, fromlist=['main'])
except ImportError:
return _MissingErrorOut(target)
return module.main()
if __name__ == '__main__':
sys.exit(main())