Skip to content
This repository has been archived by the owner on Nov 29, 2018. It is now read-only.

ENH: seperate xpdAcq profile #32

Open
CJ-Wright opened this issue May 26, 2018 · 3 comments
Open

ENH: seperate xpdAcq profile #32

CJ-Wright opened this issue May 26, 2018 · 3 comments

Comments

@CJ-Wright
Copy link
Contributor

It might be good to have an xpdAcq profile. This way we can symlink the DAMA supported profile over and add the xpdAcq files on top. This would prevent some of the issues from today about commenting out xpdAcq code.

Can we do this without ipython balking?

@CJ-Wright
Copy link
Contributor Author

@mrakitin

@mrakitin
Copy link
Member

mrakitin commented May 27, 2018

That may be not a bad idea. However, if something is not working in 999*-*.py, it makes a little difference between renaming the files to .999*-*.py and removing the symlinks in the profiles. Also, now you will have to make sure that everything is in sync on all the beamline machines, which adds more complexity in maintaining two separate profiles (tagging may become out of sync easily). I invite @danielballan and @tacaswell to discuss.

@danielballan
Copy link
Contributor

danielballan commented Aug 20, 2018

How often is the xpcacq profile changed interactively? Composing (in the sense of "combining") profiles seems like we are starting to stretch what profiles are meant for. I think it would be easier to maintain something like:

import xpdacq
xpdacq.configure(get_ipython().user_ns)  # adds objects to namespace

akin to what we do with nslsii.configure_base. What do you think of that design, @CJ-Wright?

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

No branches or pull requests

3 participants