You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 29, 2018. It is now read-only.
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?
The text was updated successfully, but these errors were encountered:
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.
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:
importxpdacqxpdacq.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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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?
The text was updated successfully, but these errors were encountered: