The env var is not currently set, so this should be a no-op. We can then set it in a branch and see how CI behaves.

That is my next task

@happy-kitchen-89482 The top of this issue is the 80/20 on how that script/system works: https://github.com/pantsbuild/pants/issues/21065 I think really the harder part is when that fails, what to do (which is like, MOSTLY in the

Get(Process)

case when you have to manually move

implicitly

around, but there are the cases where even the rule graph transformer thing that Stu wrote won’t see the Gets - e.g. in rule_helpers and whatnot. I’d wager that the overwhelming majority of plugins should be super straight-forward by comparison

@fast-school-44220 The goal itself has been around for several versions now (https://github.com/pantsbuild/pants/blob/main/src/python/pants/goal/migrate_call_by_name.py)

I am currently rewriting all the documentation… And we should create a migration page as well

That’s a find/replace… err… and import

thanks

I’d be curious if the

migrate-call-by-name

call works. I haven’t tried in quite some time, and was going to look into it later this week.

pants migrate-call-by-name pants-plugins/something::

or wherever. The code that the rule engine processes might give grief if it’s out of the pants main repository. It definitely did that when I was trying to work on the goal from mainline, to an out-of-source plugin

From this issue:

# Ensure the backend is enabled in pants.toml # backend_packages = [ # ... # "pants.backend.WHATEVER", # ... # ] pants migrate-call-by-name src/python/pants/backend/WHATEVER:: # Manually check for unnecessarily `implicitly`s and replace pants fix fmt lint check test src/python/pants/backend/WHATEVER::

“Later today” not later this week

Okay, as I suspected, call-by-name works fine in plugins, the migration goal falls over with the intentional error I left a while back.

venvs/2.29.0rc0/lib/python3.11/site-packages/pants/backend/python/util_rules/entry_points.py' is not in the subpath of 'oss/pants-plugins' OR one path is relative and the other is absolute.

I need to finally dig into this, and see why the rule graph was all janky with external plugins.

Trying to do the migration out of repo does suffer from some other problems to, which is the poor typechecking compared to mainline

@fast-school-44220 So, I ran a call-by-name on my repo here: https://github.com/sureshjoshi/pants-plugins/compare/main...call-by-name I did it using this line:

PANTS_SOURCE=../pants-from-github pants migrate-call-by-name pants-plugins/experimental/scie::

which involved cloning the main pants repo, building it, and then this. That worked, with only a couple of hiccups: • Updated the repo to a recent release • Updated my plugin resolve to use Python 3.11 •

pants generate-lockfiles --resolve=pants-plugins

•

pants export ::

- to use

./dist/export/python/virtualenvs/pants-plugins/3.11.13/

as my virtualenv in VSCode to detect certain problems ahead of time The only migration problem I had, was that

result = await Get(ProcessResult, Process, process)

this somehow got migrated into

result = await fallible_to_exec_result_or_raise(**implicitly(process))

which call-by-name can't type correctly. It needed to be

result = await fallible_to_exec_result_or_raise(**implicitly({ process: Process }))

or, what I eventually did (and what we do a lot in-repo)

result = await fallible_to_exec_result_or_raise(
        **implicitly(
            Process(
                argv=argv,
                input_digest=input_digest,
                description="Run science on the input digests",
                output_files=output_files,
                level=LogLevel.DEBUG,
            )
        )
    )

Eventually, we'd also add an update from

fallible_to_exec_result_or_raise

to

execute_process_or_raise

which is an alias in the same module. I was hoping the method I tried wouldn't work, as that would make it easy to debug so that we can run that command on the release itself

Candidate fix here for the migration script: https://github.com/pantsbuild/pants/pull/22701 - to test this, I just applied this change in my installed Pants venv, and it migrated my code

could that be because I was already calling it by name?

a quick review of the diffs looks like it did the right thing

which backend do I need active for the

pants fix fmt lint check test src/python/pants/backend/WHATEVER::

to clean up the `implicity`s?

"Fill in the blanks" is a pretty good way to describe it. A form a dependency injection, etc. Same idea as what was happening with the

Get

mechanism, but now it's more... ummm "explicily implicit"