https://pantsbuild.org/ logo
#development
Title
# development
c

curved-television-6568

02/04/2022, 4:38 PM
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.
h

hundreds-father-404

02/04/2022, 4:40 PM
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
c

curved-television-6568

02/04/2022, 4:40 PM
Uhm,
h

hundreds-father-404

02/04/2022, 4:40 PM
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
👍 1
c

curved-television-6568

02/04/2022, 4:41 PM
Instead, we know where the build root is with 
build_root.py
That would be when Pants is up and running..
OK, so there are other ways, like going up the tree, looking for the
pants
script…
h

hundreds-father-404

02/04/2022, 4:42 PM
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
Afaict, the biggest issue would be that Pants is invoked as a bash script, and it would be obnoxious to have to do
../../../../pants
c

curved-television-6568

02/04/2022, 4:43 PM
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.
h

hundreds-father-404

02/04/2022, 4:43 PM
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
oh, yeah, that is simpler 😄
So! I think that the only thing that needs to change is this
specs_calculator.py
file (and related ones) to relative specs! Nothing else you say on the CLI should care about where you're located, afaict You'd make a synchronous call to get
BuildRoot
c

curved-television-6568

02/04/2022, 4:45 PM
Yea, cool. I’ll keep this in the back of my head for a while then…
Seeing that it’s doable 🙂
h

hundreds-father-404

02/04/2022, 4:47 PM
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
c

curved-television-6568

02/04/2022, 4:53 PM
Oh, OK. I’ll start, see how far I get…
wasn’t aware it was so sought after feature 😛
💯 1
h

hundreds-father-404

02/04/2022, 4:55 PM
Yeah, if you're only working in
src/py/my_project
that day, compare this:
Copy code
./pants test src/py/my_project/utils/file.py
Copy code
./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
1
less noise
Which is a crucial part to Pants's hypothesis of ergonomics. Get rid of boilerplate because it causes noise, and noise gets in the way of seeing what really matters
c

curved-television-6568

02/04/2022, 4:57 PM
With the shim in place, we could also get rid of that
./
every where…
h

hundreds-father-404

02/04/2022, 4:57 PM
Oh true!
pants test utils/file.py
. I like it
c

curved-television-6568

02/04/2022, 4:57 PM
Now that starts looking snappy.
🙌 1
h

hundreds-father-404

02/04/2022, 4:58 PM
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
w

witty-crayon-22786

02/04/2022, 5:10 PM
one of the big challenges is relativizing all of the arguments everywhere
worth doing though
h

hundreds-father-404

02/04/2022, 5:12 PM
elativizing all of the arguments everywhere
Isn't it just specs in the CLI? Where else would it matter?
w

witty-crayon-22786

02/04/2022, 5:17 PM
all file arguments
c

curved-television-6568

02/04/2022, 5:18 PM
So, I’d say we want to do that during arg parsing, rather than touching the spec calculator..
i.e. in
ArgSplitter
w

witty-crayon-22786

02/04/2022, 5:19 PM
you’d also need to make sure that
run
and etc ran in your
cwd
rather than in the buildroot, etc. lots of considerations
1
basically, “build_root == cwd” is an assumption in various places.
c

curved-television-6568

02/04/2022, 5:20 PM
yea, there’d be dragons for a while, I’m sure..
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.
w

witty-crayon-22786

02/04/2022, 5:21 PM
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
👍 2
any callsite that began failing after that was misbehaving, and needed to choose explicitly between the buildroot and the cwd
c

curved-television-6568

02/04/2022, 5:22 PM
cool
w

witty-crayon-22786

02/04/2022, 5:23 PM
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
c

curved-television-6568

02/04/2022, 5:24 PM
Ah, right. Yea ok, so there are expectations you may break by changing directory mid-run.. hmm
OK, got a basic shim in place.
Copy code
/Users/x/src/github/kaos/pants/src/python/pants
$ pants version
21:30:27.80 [INFO] Initializing scheduler...
21:30:32.90 [INFO] Scheduler initialized.
2.10.0.dev3
Try it yourselves with:
Copy code
$ brew tap kaos/shell
$ brew install kaos/shell/pants
$ pants ....
❤️ 1
h

hundreds-father-404

02/05/2022, 1:31 AM
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
👍 1
c

curved-television-6568

02/05/2022, 2:49 PM
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..
Copy code
~/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:
Copy code
$ 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",
...
brew upgrade kaos/shell/pants
should give you
v0.2
now.. 🙂
looking for a 
BUILD_ROOT
 file
Hmm.. why? I can see the benefit, if we were to expect there not being a
pants
bootstrap script at the repo root, but until then, there’s not really a point finding a repo root, unless there is a
pants
script there for us to invoke.
That is, if we were to provide a “default” bootstrap script to fallback on otherwise…
h

hundreds-father-404

02/05/2022, 2:54 PM
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
c

curved-television-6568

02/05/2022, 2:55 PM
And then there’s stuff like this to consider too..
Copy code
$ pants help goals
Unknown entity: src/python/pants/backend/docker/goals
doh. 😛
👍 1
That allows you to do things like rename 
./pants
 to instead be 
./my_org
.
Ah, but for that you’d do
Copy code
PANTS_BIN_NAME=my_org pants ...
and it would look for
my_org
rather than
pants
script.