Was there any problem with using workspace? I found using workspace (additional repository clone) is useful. Developing the script is simpler if we have 1 repository clone for new-client.py development and 1 repository clone for generated new client.

If you came up with a good way to develop new-client.py within 1 repository copy while testing library generation, I want to know the method (It's worth writing down in generation/new_client/README.md).

Was there any problem with using workspace? I found using workspace (additional repository clone) is useful. Developing the script is simpler if we have 1 repository clone for new-client.py development and 1 repository clone for generated new client.

The problem with the workspace is that you can't make changes to the new-client.py script and test them without pushing upstream. It also makes it not hermetic. Additionally, there's overhead with checking out the whole repository first, when you already have it. Can you explain how development is easier with two different git repositories in one workspace?

If you came up with a good way to develop new-client.py within 1 repository copy while testing library generation, I want to know the method (It's worth writing down in generation/new_client/README.md).

This PR allows you to develop new-client.py within the same repository copy. That's exactly what I did while preparing this PR and generating #8646. I just excluded new-client.py from committing with the new module and created a separate PR.

you can't make changes to the new-client.py script and test them without pushing upstream.

In HOME/google-cloud-java you create a development branch for new-client.py (e.g., new-client-changes). You run new-client.py script and it creates HOME/google-cloud-java/generation/workspace/monorepo (e.g., new_module_java-discoveryengine). These two branches are separated; you don't have to push new-client-changes to main (upstream).

Can you explain how development is easier with two different git repositories in one workspace?

Having separate repository clones make the branches maintenance easier. 2 repository copy, 2 branches, and 2 pull requests.

I just excluded new-client.py from committing with the new module and created a separate PR.

Good. That works Can you add that instruction to README?

you can't make changes to the new-client.py script and test them without pushing upstream.

In HOME/google-cloud-java you create a development branch for new-client.py (e.g., new-client-changes). You run new-client.py script and it creates HOME/google-cloud-java/generation/workspace/monorepo (e.g., new_module_java-discoveryengine). These two branches are separated; you don't have to push new-client-changes to main (upstream).

The reason you have to push all the way to main is this line:

    subprocess.check_call(["git", "clone", monorepo_url, "monorepo"],
                          cwd="workspace")

It makes the starting point the main branch. Although new-client.py that is executed is in your local branch, it calls scripts that are coming from the remote main.

    subprocess.check_call(
        ["bash", "generation/update_owlbot_postprocessor_config.sh"],
        cwd=monorepo_root
    )

Where monorepo_root is the workspace directory that has code from main. So, you can't test changes to any of these files without pushing them upstream. It's not about new-client.py specifically, but other scripts it calls.