Skip to content
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

ARCA_BASE_DIR can depend on the current directory #59

Open
encukou opened this issue Dec 27, 2018 · 4 comments
Open

ARCA_BASE_DIR can depend on the current directory #59

encukou opened this issue Dec 27, 2018 · 4 comments

Comments

@encukou
Copy link
Member

encukou commented Dec 27, 2018

When I set a relative ARCA_BASE_DIR and then call os.chdir(), Arca starts looking for its files in the new location.
IMO it should be fixed at initialization.

@mikicz
Copy link
Member

mikicz commented Jan 19, 2019

I get what you mean... The problem is of course that the value is lazily resolved only when needed (if not set directly in initialization), which then makes it hard to resolve and fix in __init__.

Is this a big problem? Do you run at least one task before doing the os.chdir()? If so I could code in a callback of some to freeze the location, alternatively I could just add a method which would freeze the location...

@encukou
Copy link
Member Author

encukou commented Jan 21, 2019

The problem is of course that the value is lazily resolved only when needed (if not set directly in initialization), which then makes it hard to resolve and fix in __init__.

I actually don't understand why it's needed to be resolved lazily. What would be the downsides of resolving it in __init__?

@mikicz
Copy link
Member

mikicz commented Jan 21, 2019

Because it can be determined by the settings dictionary and that could be in theory modified even after being passed to Arca. I can resolve it in __init__ and add a warning to documentation that in the case of this option this is the behaviour...

@encukou
Copy link
Member Author

encukou commented Jan 29, 2019

Because it can be determined by the settings dictionary and that could be in theory modified even after being passed to Arca.

It can be modified only until Arca (or something else) accesses that attribute. That sounds like ill-defined behavior: if some unrelated code (or some future Arca version) happens to resolve the value before it's modified, the settings dictionary won't have any effect.

Or is the time when the settings dictionary can still be changed well defined?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants