feat(actions): expose python-path output and propagate it to build-wheelhouse

[germa89]

I believe it makes more sense to export the python path, so it can be used as an env var:

- name: "Build wheelhouse"
  uses: ansys/actions/build-wheelhouse@main
  with:
    library-name: ${{ env.LIBRARY_NAME }}
    operating-system: ${{ matrix.os }}
    python-version: ${{ env.MAIN_PYTHON_VERSION }}
    working-directory: .ci/${{ env.LIBRARY_NAME }}
    attest-provenance: true

- name: "do something..."
  env:
    PYTHON: ${{ steps.build-wheelhouse.output.python-path }}
  run:
    python something.py

Potentially you could do (I will need a double check):

- name: "do something..."
  shell: python
  env:
    PYTHON: ${{ steps.build-wheelhouse.output.python-path }}
  run:
    # my python code
    from ansys.mapdl.core import launch_mapdl

Or maybe we can do something like:

- name: "do something..."
  shell: ${{ steps.build-wheelhouse.output.python-path }} {0}
  run:
    # my python code
    from ansys.mapdl.core import launch_mapdl

Changes

• Add python-path output and a "Get Python path" step to the _setup-python composite action.
• Add id: setup-python to the build-wheelhouse setup step and expose python-path via steps.setup-python.outputs.python-path.

[SMoraisAnsys]

Shouldn't you be retrieving the virtual env instead of the python installation ? If yes, I think that it would make more sense to expose steps.virtual-environment-activation-command.outputs.ACTIVATE_VENV instead.

[germa89]

Hi @SMoraisAnsys

You are right, I was retrieving the python installation. The idea should be to retrieve the venv python executable. I fixed that now.

I still think it is more interesting to retrieve the executable path than the activation command, for the reasons I mentioned in the PR (I updated it).

Please feel free to review!

[jorgepiloto]

The actions were designed to be unique jobs. I have the feeling that the more flexibility and options we add, the more challenging it is to maintain them.

[RobPasMue]

I fully agree with @jorgepiloto on this one... also, we shouldn't be performing extra operations after the wheelhouse has been built

[germa89]

I fully agree with @jorgepiloto on this one... also, we shouldn't be performing extra operations after the wheelhouse has been built

I agree... but I think we mentioned that we might need to run some custom smoke tests after the build. That is why the other output activate_venv was implemented. But that option (export commands to activate a venv) is a bit non-standard, hence I was proposing this solution.

[RobPasMue]

Why not activate the venv and run python normally then?

[SMoraisAnsys]

Sorry but I find it difficult to grasp the added value associated with these changes. Since we already have the activate-venv output, can't you just leverage that directly ?

[RobPasMue]

Yeah .. I'd recommend to just avoid this. Please use activate_venv @germa89. Proposing to close this PR..