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

[ENH] - Improved working directory support #520

Open
mcg1969 opened this issue Nov 11, 2024 · 0 comments
Open

[ENH] - Improved working directory support #520

mcg1969 opened this issue Nov 11, 2024 · 0 comments

Comments

@mcg1969
Copy link

mcg1969 commented Nov 11, 2024

Feature description

From the docs:

Also, be aware that jhub-apps may be launching your app from a different directory than you used during development. Therefore, its important to always define absolute paths in your apps. For example, if you use pathlib to define a path, you'll need to call .resolve() in order to make it absolute.

This should not be so, in my view. It is reasonable for application developers to assume that the working directory of their application is relative to the notebook or script being run—in fact, most commonly, the working directory is the location of said notebook or script. This allows them to use relative paths to load datasets or other assets.

Breaking this assumption is going to saddle application developers with the requirement to write additional code throughout their application that resolves relative paths. Indeed, it's not actually clear to me how a notebook is supposed to even determine where it lives. At least with a script I have the __file__ magic variable, but I am unaware of an equivalent for notebooks. And of course, the minute an application is shared with others, that code might need to be changed.

My preference is that the default working directory is the os.path.dirname of the script or notebook. If this could be made configurable, that would be good, but honestly it's difficult for me to see the value in doing anything different.

Value and/or benefit

See above

Anything else?

No response

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

1 participant