Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

feat: add Actor exit_process option #424

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Mar 5, 2025
Merged

feat: add Actor exit_process option #424

merged 5 commits into from
Mar 5, 2025

Conversation

vdusek
Copy link
Contributor

@vdusek vdusek commented Mar 4, 2025

Description

  • Introduced a new exit_process option for the Actor class.
  • Named the option exit_process (instead of exit) to avoid shadowing Python's built-in names.
  • Set reasonable defaults: False for IPython, Pytest, and Scrapy environments, and True for all other cases.
  • Updated the test_actor_logs_messages_correctly test accordingly.

Issues

Tests

  • Tests are passing, including the Scrapy integration test.

@vdusek vdusek requested review from Mantisus and Pijukatel March 4, 2025 15:43
@vdusek vdusek self-assigned this Mar 4, 2025
@vdusek
Copy link
Contributor Author

vdusek commented Mar 4, 2025

Hi @honzajavorek, what were your suggestions for utilizing the Scrapy's get_project_settings?

@github-actions github-actions bot added this to the 109th sprint - Tooling team milestone Mar 4, 2025
@github-actions github-actions bot added t-tooling Issues with this label are in the ownership of the tooling team. tested Temporary label used only programatically for some analytics. labels Mar 4, 2025
src/apify/_actor.py Show resolved Hide resolved
@B4nan
Copy link
Member

B4nan commented Mar 5, 2025

Named the option call_exit (instead of exit) to avoid shadowing Python's built-in names.

Is this really necessary? I would rather keep the same naming as in the JS version. I recall this argument from another PR, where @janbuchar disagreed with the shadowing being necessary?

@vdusek
Copy link
Contributor Author

vdusek commented Mar 5, 2025

Is this really necessary? I would rather keep the same naming as in the JS version. I recall this argument from another PR, where @janbuchar disagreed with the shadowing being necessary?

Not strictly necessary, just good practice and keeping the linter happy. However, the built-in exit is primarily for interactive use, so it's not that big deal, and keeping argument names consistent is a good argument (although the Actor interfaces differ quite a lot just because of the context managers in Python). Any thoughts, @Pijukatel? Honza is already tagged.

@Pijukatel
Copy link
Contributor

Is this really necessary? I would rather keep the same naming as in the JS version. I recall this argument from another PR, where @janbuchar disagreed with the shadowing being necessary?

Not strictly necessary, just good practice and keeping the linter happy. However, the built-in exit is primarily for interactive use, so it's not that big deal, and keeping argument names consistent is a good argument (although the Actor interfaces differ quite a lot just because of the context managers in Python). Any thoughts, @Pijukatel? Honza is already tagged.

I am leaning towards call_exit as it is still quite similar to JS version, only adapted to Python world, but I do not have strong opinion about this and I am quite ok with also having exit + ignore.

@janbuchar
Copy link
Contributor

Is this really necessary? I would rather keep the same naming as in the JS version. I recall this argument from another PR, where @janbuchar disagreed with the shadowing being necessary?

Not strictly necessary, just good practice and keeping the linter happy. However, the built-in exit is primarily for interactive use, so it's not that big deal, and keeping argument names consistent is a good argument (although the Actor interfaces differ quite a lot just because of the context managers in Python). Any thoughts, @Pijukatel? Honza is already tagged.

In general, I'm pro-shadowing and will always argue in favor of shadowing obscure Python builtins 😁 However, exit on its own is not exactly self-explanatory as a parameter name. call_exit might work better, but I feel that an even better name exists... Something like exit_process maybe?

@B4nan
Copy link
Member

B4nan commented Mar 5, 2025

I can't help myself, but the call_ prefix sounds really weird to me.

@vdusek
Copy link
Contributor Author

vdusek commented Mar 5, 2025

I have no problem changing to e.g. exit_process as was suggested.

@B4nan
Copy link
Member

B4nan commented Mar 5, 2025

Let's go with exit_process, that sounds much better.

@vdusek vdusek changed the title feat: add Actor call_exit option feat: add Actor exit_process option Mar 5, 2025
@vdusek vdusek requested a review from Pijukatel March 5, 2025 11:31
Copy link
Collaborator

@Mantisus Mantisus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@vdusek vdusek merged commit 994c832 into master Mar 5, 2025
29 checks passed
@vdusek vdusek deleted the add-actor-exit-flag branch March 5, 2025 12:45
@honzajavorek
Copy link
Contributor

honzajavorek commented Mar 5, 2025

LGTM.

My idea was to use get_project_settings() instead of checking the env var, because checking one env var isn't sufficient to detect we're inside a Scrapy project. But I didn't experiment with get_project_settings() enough to see whether it has side effects, or whether it's actually possible to easily distinguish settings created from a project and from a "no project".

This change detects Scrapy by checking whether it's installed, which might not be perfect (perhaps I could use something from Scrapy, but not the whole thing? how many scrapers like that exists? probably not many 🤔 ), but the most important change is that if I realize the SDK doesn't do a great job in detecting my particular use case, I can now explicitly say "please do not call sys.exit()", no bizarre hacks needed. Thanks!

This closes #389 as well.

@vdusek
Copy link
Contributor Author

vdusek commented Mar 5, 2025

Thanks, @honzajavorek. I tried using get_project_settings, but I didn't find anything useful for detecting a Scrapy project there. So I stayed with simply trying to import the scrapy package. This can lead to false positives, of course, but it's probably still improvement over the current approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
t-tooling Issues with this label are in the ownership of the tooling team. tested Temporary label used only programatically for some analytics.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Relying on SCRAPY_SETTINGS_MODULE isn't sufficient Refactor sys.exit handling for tests in Actor
6 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.