Or it should support triggering another action from a javascript action, e.g.

import * as actions from '@actions/actions'; // <-- this is new
import * as exec from '@actions/exec';
await actions.run('setup-python', {python-version: '2.x'});
await exec.exec('pip install ...');

It's not particularly pretty, but I think I've found a way to include setup-python as a dependency and execute it.

Add the repository as a dependency and specify a version.

npm i --save actions/setup-python#v2.0.1

It will get added to package.json like this.

  "dependencies": {
    "setup-python": "github:actions/setup-python#v2.0.1"
  }

Add a script in package.json to build setup-python.

  "scripts": {
    "build-setup-python": "npm install --prefix node_modules/setup-python && npm run build --prefix node_modules/setup-python"
    ...
  }

Install and build (Add this to CI, too)

npm install
npm run build-setup-python

It should build and be usable as in this example:

import * as core from '@actions/core'
import * as setupPython from 'setup-python/lib/find-python'

async function run(): Promise<void> {
  try {
    const installed = await setupPython.findPythonVersion('3.x', 'x64')
    core.info(`Successfully setup ${installed.impl} (${installed.version})`)
  } catch (error) {
    core.setFailed(error.message)
  }
}

run()

@peter-evans right, npm supports installing straight from a GitHub repo like you've found.

I think if we were publishing as an NPM package, we would want to do more work around giving the action a proper API and versioning the NPM package around that. So, if the existing path that npm provides is working well, I think that's a better alternative than taking on the dev and maintenance cost of a full-on package.

@brcrista It feels a bit hacky so I don't think it's a great solution long term. It would be nice if the logic existed in an actions/tookit module and this action was just a wrapper that called it.

For my own use case, I'm planning to move away from executing Python with actions/exec and convert to Typescript. So eventually this will be a non-issue for me, but others may still appreciate a better solution in future.

That makes sense -- just a matter of whether the time spent and added complexity is worth it. I'm going to close this as we're not planning on this work right now, but we'll keep this in mind if people keep asking for it.

I was watching this thread without speaking up. I would also like a way to ensure that a specific version of Python is installed from another action, to simplify the requirements for others who depend on the action.

fwiw I've been pretty disappointed with the reusability of github actions, the design choices of having executable git repos make it really difficult to compose actions (instead they must be copy pasted everywhere) and with a lack of support for template repositories (such as with azure pipelines) means there really isn't any solution for things like this beyond adding more to copy paste

my particular usecase for having an in-process runnable setupPython is to patch a (imo) pretty glaring omission in this action: setting up in-development versions. the current implementation requires copy pasting two actions both with disparate complex conditionals. the ideal case would be a single action which just works (by calling out to setup-python in some way when it cannot handle the particular versions itself): deadsnakes/issues#123

FWIW one way in another action we found to compose actions is to simply download the resulting dist/index.js file: ruby/setup-ruby#33 (comment)

Check out this issue for "composite actions:" actions/runner#438. There's also a working design proposal: actions/runner#554

I think this would address @peter-evans 's and @foolip 's scenarios. @asottile , this isn't the same templating model as Azure Pipelines, but I think that could address your use case also.