-
Notifications
You must be signed in to change notification settings - Fork 40
Description
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! 🙏