Pants: investigate ./pants wrapper script for relative target paths

[cosmicexplorer]

It would be really interesting to have some sort of wrapper for the ./pants runner script which resolves target paths relative to the current directory. I'm thinking an example if implemented as a bash function pants_wrapper would allow something like:

> cd /path/to/pants/clone
> cd src/python/pants
> pants_wrapper -q repl ./util:

Python 2.7.15 (default, Jun 20 2018, 17:40:09) 
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>

In a monorepo, this would allow working in some specific directory with some local files, then allow running pants on targets in that directory. This would also allow having multiple terminal sessions open at once in different directories of a monorepo to maintain WIP state in multiple directories at once.

There may be other benefits to using such a wrapper, and other transformations we can do besides just resolving target paths differently! I'm thinking implementing pants_wrapper above would probably involve a shell function that just invokes pants at the root with some wrapper script, while there may be some special logic in ArgSplitter if, say, a specific environment variable PANTS_RELATIVE_DIR or something is set in the pants invocation to resolve target specs relative to the directory path in that env var (which itself is relative to the buildroot).

@ShaneDelmore has brought this up multiple times and may have more input on what might be useful about this, especially as it appears sbt is able to do something like the terminal output above?

[cosmicexplorer]

This might also be a great way to encourage the use of dir_option and file_option (compared to a string option) if we can just resolve those relative to PANTS_RELATIVE_DIR as well.

[ShaneDelmore]

I would love to be in sourceroot, cd into sandbox/users/sdelmore/log-collector and then just run
pants test
for example. I've already set my context by cding into the dir, it would be great not to have to repeat my context every command by typing pants compile sandbox/users/sdelmore/log-collector

[ShaneDelmore]

Currently I've been doing this in scripts:

#!/usr/bin/env bash

SCRIPTDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

PANTSDIR=${SCRIPTDIR}
while [ ! -e "$PANTSDIR/.pants.d" ]; do
  PANTSDIR=${PANTSDIR%/*}
  if [ "$PANTSDIR" = "" ]; then break; fi
done

[cosmicexplorer]

@stuhood noted that it would be reasonable to resolve options in-process rather than in the wrapper (thanks!) -- I'm thinking a --relative-dir bootstrap option (which could also then be specified with PANTS_RELATIVE_DIR like all pants options) would be usable to resolve dir_option and file_option paths.

[ShaneDelmore]

Another use case that would be nice while you're asking for use cases. pants idea-plugin .

[cosmicexplorer]

> pants idea-plugin .

I think this might be a fantastic entry to have in the "getting started" section of the docsite.

[cosmicexplorer]

https://github.com/bzl-io/bzl is an analogous (I think) wrapper for bazel! We could look to this tool for inspiration on what to implement first.

[cosmicexplorer]

One possibility I've scavenged from an internal slack to allow running a function pants in any subdirectory is:

function pants() {
  pushd "$(git rev-parse --show-toplevel)" >/dev/null
  ./pants "$@"
  popd >/dev/null
}

function pants-rel() {
  local prefix="$(git rev-parse --show-prefix)"
  # First n-1 args untouched; prepend prefix to last arg (assumed to be target)
  pants "${@:1:$#-1}" "$prefix${@:$#}"
}

This should be edited to traverse parent directories to search for a ./pants file instead of using git, though.