10000 Current working directory agnostic onager · Issue #51 · camall3n/onager · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Current working directory agnostic onager #51

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.

Sign up for GitHub

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

Jump to bottom
Open
taodav opened this issue Feb 8, 2023 · 1 comment
< A8BF span title="Status: Open" data-view-component="true" class="State State--open d-flex flex-items-center"> Open

Current working directory agnostic onager #51

taodav opened this issue Feb 8, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@taodav
Copy link
taodav commented Feb 8, 2023

Currently, onager saves its prelaunch and history files and data in what is assumed to be the current working directory's .onager folder.

Ideally what should happen is that the .onager always references an .onager file in the project root (or the parent of the currently activated virtualenv).

This way you can run any onager command from any directory, as long as your virtualenv is activated.
@camall3n camall3n added the enhancement New feature or request label Feb 8, 2023
@camall3n
Copy link
Owner
camall3n commented Feb 8, 2023 •
edited
Loading

I like this idea. It would allow launching jobs from subdirectories, and it elegantly sidesteps the problem searching up and down the directory tree for where the .onager folder is.

However, I also see at least one potential issue...

Not everyone puts their virtual env in the code directory; some people use a single virtual env for multiple projects and put it somewhere like ~/venvs. This would mean job logs would be harder to access. Currently the workflow is

cd .onager/logs/slurm

If we made this change, the workflow for those people would get a lot more annoying:

cd ~/path/to/.onager/logs/slurm

This could be mitigated by something like an onager log command. We already have onager history and onager list, so we could potentially use similar functionality for something that allows viewing log files. But it might still slow things down since it wouldn't be able to do tab-completion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@camall3n @taodav
0