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

Add ability to ignore (specific?) upstream devices in load #297

Open
ZLLentz opened this issue Oct 15, 2021 · 4 comments
Open

Add ability to ignore (specific?) upstream devices in load #297

ZLLentz opened this issue Oct 15, 2021 · 4 comments

Comments

@ZLLentz
Copy link
Member

ZLLentz commented Oct 15, 2021

Expected Behavior

Hutch user should get exactly which objects they want and none (or few) extra

Current Behavior

Hutch user currently gets all hutch devices plus all upstream devices based on the lightpath

Possible Solution

  • config/cli option (--no-upstream? --no-lightpath?)
  • more precise config control (--beamlines xpp lfe, --ignore xpp)

Steps to Reproduce (for bugs)

  1. Open a session in e.g. mec who is very far downstream

Context

Does MEC need to see LODCM errors? I don't think they care.

@ZryletTC
Copy link
Contributor

ZryletTC commented Oct 15, 2021

This makes sense and is somewhat similar to another thing desired by xpp, an option for not loading camViewer devices. I was playing around with adding an option to the conf.yaml file. What do you think of putting these options in there? I would also vote for more fine control than just a --no-upstream or similar option.

@klauer
Copy link
Contributor

klauer commented Oct 15, 2021

What if you could specify sets of happi search queries you wanted to include (or exclude)?

@ZLLentz
Copy link
Member Author

ZLLentz commented Oct 28, 2021

Related: RIX would like to add specific beamlines to their config, namely: it currently loads RIX and KFE, but they'd also like to see CRIX_MODS. We should bundle the ability to add specific beamlines (and as Ken says, arbitrary queries) in addition to removing them.

The current default is sensible, but maybe it should be fully configured instead of assumed?

@ZLLentz
Copy link
Member Author

ZLLentz commented Oct 28, 2021

(also, small reminder that the defaults are defined in lightpath, which isn't really a sensible place for this sort of config)

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

3 participants