Skip to content

Actor Entrypoint configuration #766

@vladfrangu

Description

@vladfrangu

A common issue with CLI users is our rudimentary attempt at discovering your Actor's entrypoint (see #761, #746, #271).

Right now, apify init will use our attempt at detecting a node/scrapy/python project, and same with apify run. Neither of these commands store the actual "entrypoint" command anywhere, and both of these commands are super fragile to a project structure that doesn't conform to our "expectations" (specifically visible with apify run on a python project that doesn't have a src/__main__.py file.

This is very much not ideal, and, after discussing with @netmilk, he agreed. Within our discussions, we proposed expanding actor.json with the following object:

const actor = {
    // existing actor.json fields,
    localDevelopment: {
        command: 'command to run to start your project',
    },
};

This would define the de-facto command that we run when calling apify run (except when --entrypoint is provided).

This would be prefilled by apify init if we detect structures (like a node project with package.json, where we infer from the main property, or us looking for a src/__main__.py file in python projects), or prompted to the user (for instance in a rust project, users would have to pass in cargo run for example)

This would also allow users to chain commands (for instance npm run build && npm test && npm start).

In the long run, this could also open up a way for us to try and replicate platform's build & run systems, by building the Docker image locally and starting it too. @netmilk actually has written a bash script that does just that, and this would open up support for that natively in CLI.

Looking for thoughts! 🙏

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request.t-toolingIssues with this label are in the ownership of the tooling team.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions