Four days ago, Python installed to /opt/hostedtoolcache, but today it installed to .../_work/_tool.
See original GitHub issueDescription:
Four days ago, Python installed to /opt/hostedtoolcache
, but today it installed to .../_work/_tool
. This manifested as a failure to find Python.h
while building the native dependencies of python-ldap
. Somehow, the installation procedure of python-ldap
knew to put -I/opt/hostedtoolcache/Python/3.8.10/x64/include/python3.8
on the command line, but there was nothing in the /opt/hostedtoolcache
folder. I’m currently working around this by setting the AGENT_TOOLSDIRECTORY
environment variable to /opt/hostedtoolcache
in my workflow.
Action version: b55428b1882923874294fa556849718a1d7f2ca5
Platform:
- Ubuntu
- macOS
- Windows
Runner type:
- Hosted
- Self-hosted
Tools version: 3.8.10
Repro steps:
- name: Install Python 3.8.10
uses: actions/setup-python@b55428b1882923874294fa556849718a1d7f2ca5
with:
python-version: '3.8.10'
Expected behavior:
I would expect this to install Python to /opt/hostedtoolcache
like it previously did.
Actual behavior:
It now installs Python to .../_work/_tool
within the job’s workspace.
Issue Analytics
- State:
- Created a year ago
- Comments:13
Top GitHub Comments
I encountered this as well, although the self-hosted runner I’m using has not used
/opt/hostedtoolcache
since it was installed months ago./opt
is completely empty and the runner user does not have write access to it;actions/setup-python
appears to have always put Python in the_work/_tool
subdirectory.Since I did not want to change the runner’s configuration, I worked around the problem by setting the
CFLAGS
env var in my actions workflow, e.g.:This let my build find
Python.h
successfully.However, nothing has changed recently with the runner, the workflow, or the Python version I’m using, so I’d love to understand why it’s now getting the include path wrong.
Was able to apply a workaround by adding an environmental variable, as TS mentioned: