Is it assumed that any project using Pants, is also using git for version control? I’ve found myself a few times now wishing I could invoke pants from any directory, not just the root of the repo. And using

git rev-parse --show-toplevel

seems like a robust way of locating the repo root, in case of git repos at least. And in doing so, any specs could be treated as relative to where you invoked pants.

is also using git for version control?

Not a requirement. You only need it for

--changed-since

to work. We have a call to action, *in our error message if Git is not supported, if someone wants support for other VCS to put in a feature request -- Instead, we know where the build root is with

build_root.py

Uhm,

I’ve found myself a few times now wishing I could invoke pants from any directory, not just the root of the repo.

Absolutely, this is one of our most requested features. It would be such a huge win for ergonomics

Instead, we know where the build root is with 

build_root.py

That would be when Pants is up and running..

That would be when Pants is up and running..

We can request the

BuildRoot

more eagerly through a synchronous engine request: https://github.com/pantsbuild/pants/blob/c52d2cd27152a79d00237d88ce0f299c6a944b8a/src/python/pants/init/specs_calculator.py#L60-L66

Yeah, there’d have to be a tiny shim, locating the pants script and invoking it. If that is installed as a system binary, or just as a function that you “activate”… toss up.

Which then gets us into "Distribute Pants as a globally installed binary!" Which we'd love to do, as you know. Although we will want to retain the ability for each individual repo to set their Pants version -- Pants manages versions for you, not user

Yea, cool. I’ll keep this in the back of my head for a while then…

I'm super excited for this idea! Really high impact. I could try to take a look at the Specs code if that's helpful -- I've spent a whole lot of time there, and will continue to with the Specs redesign Pt 2 I've proposed The trickier part for me would be that shim you describe

Oh, OK. I’ll start, see how far I get…

Yeah, if you're only working in

src/py/my_project

that day, compare this:

./pants test src/py/my_project/utils/file.py

./pants test utils/file.py

Yeah, there's tab auto-complete, but so much more convenient to do the latter. And easier to understand, less noise

With the shim in place, we could also get rid of that

./

every where…

Oh true!

pants test utils/file.py

. I like it

Now that starts looking snappy.

Now that starts looking snappy.

Which is another reason I'm so excited by the potential here. Every single Pants user interacts with the CLI, every single time. Compared to things like BUILD file management often being only used primarily by power users

one of the big challenges is relativizing all of the arguments everywhere

elativizing all of the arguments everywhere

Isn't it just specs in the CLI? Where else would it matter?

all file arguments

So, I’d say we want to do that during arg parsing, rather than touching the spec calculator..

you’d also need to make sure that

run

and etc ran in your

cwd

rather than in the buildroot, etc. lots of considerations

yea, there’d be dragons for a while, I’m sure..

one of the suggestions that we had on sandboxing might actually help catch/enforce proper behavior everywhere: having pants capture the buildroot and cwd, and then change into a temporary directory that it then deleted. that would cause all calls to

os.getcwd

to fail (including relative path lookups), and help enforce good hygiene

cool

perhaps actually it would be safer to 

cd <repo root>

 before invoking 

./pants

 and do the relativizing of the cli args outside of pants only.

@curved-television-6568: maybe… i’m not sure that that is easier. that wouldn’t work for

run

, for example

Ah, right. Yea ok, so there are expectations you may break by changing directory mid-run.. hmm

Sweet! Btw, we'd eventually want it to have the full logic of

build_root.py

I think, like looking for a

BUILD_ROOT

file alternatively. But this is awesome starting point

Made some tweaks, so adding the relpath from repo root to what looks like file args already in the shim seemed like an easy fix. Haven’t tried it a lot, but should cover the easiest cases at least.. like

list

works nice..

~/src/github/kaos/pants/src/python/pants/backend/docker (main *)
$ pants list .::
src/python/pants/backend/docker:docker
src/python/pants/backend/docker:tests
src/python/pants/backend/docker/__init__.py
src/python/pants/backend/docker/package_types.py
src/python/pants/backend/docker/register.py
src/python/pants/backend/docker/registries.py
src/python/pants/backend/docker/registries_test.py:tests
src/python/pants/backend/docker/rules.py
src/python/pants/backend/docker/target_types.py
src/python/pants/backend/docker/utils.py
src/python/pants/backend/docker/utils_test.py:tests
src/python/pants/backend/docker/value_interpolation.py

Using the

.

there to indicate my current dir rather than all targets, as

pants list ::

would (still) do. Also, this works nice:

$ pants peek util_rules/dockerfile.py
[
  {
    "address": "src/python/pants/backend/docker/util_rules/dockerfile.py",
    "target_type": "python_source",
    "dependencies": [
      "src/python/pants/backend/docker/target_types.py",
...

That support comes from https://github.com/pantsbuild/pants/pull/8105. I think it'd be important to have parity with Pants itself, if it only needs

BUILD_ROOT

and no

./pants

script, all power to you. That allows you to do things like rename

./pants

to instead be

./my_org

. Relates to Joshua's thread on how to reference

./pants

And then there’s stuff like this to consider too..

$ pants help goals
Unknown entity: src/python/pants/backend/docker/goals

doh. 😛