pantsbuild #development

Channels

welcome

github-notifications

development

aloof-angle-91616

02/20/2020, 10:29 PM

or https://www.pantsbuild.org/dev_tasks.html#fine-tuning-options, which is probably what you want

hundreds-breakfast-49010

02/20/2020, 10:29 PM

hm, if we do

./pants --v2 --no-v1 <goal> --help

, right now we're getting help results for both the v2 and v1 versions of that goal

hundreds-breakfast-49010

02/20/2020, 10:29 PM

I thought that was something we had fixed?

hundreds-father-404

02/20/2020, 10:38 PM

All we changed was

./pants --no-v1 --v2 goals

, not

--help

hundreds-breakfast-49010

02/20/2020, 10:39 PM

ah, I might've been misremembering what had changed

hundreds-breakfast-49010

02/20/2020, 10:39 PM

but we should make a similar change to

--help

, right?

👍 2

aloof-angle-91616

02/20/2020, 10:39 PM

yes!

aloof-angle-91616

02/20/2020, 10:39 PM

would love to help if needed

hundreds-father-404

02/20/2020, 10:57 PM

Yes, we should make the change. Might be good to open an issue

hundreds-breakfast-49010

02/21/2020, 1:28 AM

what's the best way to tell if we're running v2 or v1 in

local_pants_runner.py

hundreds-breakfast-49010

02/21/2020, 1:34 AM

or maybe a better question is, why do we invoke both

maybe_run_v1

and

maybe_run_v2

there, at the same time, and presumably relying on

self.__options._goals_by_version

to figure out what exactly to run?

hundreds-breakfast-49010

02/21/2020, 1:34 AM

rather than checking the local

_options

member for

v1

v2

hundreds-father-404

02/21/2020, 1:35 AM

It’s possible to run both V1 and V2 goals at the same time.

./pants --v1 --v2 fmt fmt2 ::

. It’s also possible to run ambiguous goals at the same time,

./pants --v1 --v2 test ::

will run test with both the V1 and V2 implementations

hundreds-breakfast-49010

02/21/2020, 1:36 AM

so that means that it's possible in principle for the

--help

flag to be ambiguous too, right?

hundreds-breakfast-49010

02/21/2020, 1:36 AM

./pants --v2 --v1 test --help

hundreds-breakfast-49010

02/21/2020, 1:36 AM

what should the behavior here be?

hundreds-father-404

02/21/2020, 1:48 AM

It should print the help for both the V1 and V2 implementations, imo

hundreds-breakfast-49010

02/21/2020, 2:08 AM

I'm not done with this yet and it's not typechecking but feel free to look at https://github.com/pantsbuild/pants/pull/9158

hundreds-breakfast-49010

02/22/2020, 2:05 AM

does anyone understand how the

IPython

subystem currently works?

hundreds-breakfast-49010

02/22/2020, 2:06 AM

it looks like this might be just a wrapper around an ipython package name/version for the purpose of making a pex with ipython in it using the v1 pex infrastructure

hundreds-breakfast-49010

02/22/2020, 2:06 AM

if that's all it's doing then I think it makes sense not to use it at all in a v2 implementation of an ipython repl

hundreds-father-404

02/22/2020, 4:52 AM

It’s important that we continue to use the subsystem. For example, cruise uses

—ipython-version

to change the version to the one they want. This will be very similar to how we do the V2 linters, where we have a subsystem for the underlying tool. To use it in a rule, simply declare subsystem_rule(IPython) and request it as a param to the rule

happy-kitchen-89482

02/22/2020, 5:40 AM

All any subsystem is, is a wrapper around some config

☝️ 2

👖 2

aloof-angle-91616

02/24/2020, 4:49 PM

there are probably a few more of these: https://github.com/pantsbuild/pants/blob/master/src/python/pants/engine/selectors.py#L23-L24

Copy code

@frozen_after_init
@dataclass(unsafe_hash=True)
class Get(Generic[_Product]):
    """Experimental synchronous generator API.
    May be called equivalently as either:   # verbose form: Get[product](subject_declared_type,
    subject)   # shorthand form: Get[product](subject_declared_type(<constructor args for subject>))
    """

aloof-angle-91616

02/24/2020, 4:49 PM

easy to fix

hundreds-father-404

02/24/2020, 6:37 PM

With “to fix”, do you mean removing the untyped Get syntax?

hundreds-breakfast-49010

02/25/2020, 1:20 AM

I'm running into a weird issue trying to modify the repl integration tests in this draft PR for adding ipython support: https://github.com/pantsbuild/pants/pull/9171

hundreds-breakfast-49010

02/25/2020, 10:12 PM

what's the best way to figure out what the signature of the

bazel_protos::remote_execution::*

types are?

hundreds-breakfast-49010

02/25/2020, 10:12 PM

we're autogenerating those from protobuf specs right? I'm not sure how to tell how those end up manifesting in rust

hundreds-father-404

02/26/2020, 1:13 AM

Figured out some prework I can do for the Target API project..more closely unify

TargetAdaptor

and

HydratedTarget

. Turns out,

HydratedTarget

doesn’t store any information not contained in

TargetAdaptor

hydrated_target.address == hydrated_target.adaptor.address

and

hydrated_target.dependencies == hydrated_target.adaptor.dependencies

. The proposal is: 1) Remove

dependencies

and

address

as fields on

HydratedTarget

HydratedTarget

only has one field

TargetAdaptor

2) Add a method on

TargetAdaptor

to convert back to a

HydratedTarget

by calling

HydratedTarget(self)

3) Possibly rename

HydratedTarget

to something like

TargetWrapper

GenericTarget

? Why keep

HydratedTarget

? We need it for the type-driven graph to work properly. A

HydratedTarget

is a generic wrapper around different target classes, whereas a

TargetAdaptor

has different types like

PythonTestsAdaptor

and

PythonLibraryAdaptor

. We need to be able to work with targets both generically and depending on their target type (i.e. unions) Thoughts?

🔥 1