Discussion on pro/cons of moving profile content in repo

[danielballan]

My understanding is that we plan to gradually move IPython profile content into this package, such that a beamline's IPython "startup" configuration is reduced to:

from nsls2tools.BEAMLINE.startup import *

IPython profiles can continue to be used for personal customization, which is what IPython intends them for.

In my view, the rationale for this change is:

• With bluesky and ophyd 1.0 coming up, it's natural time to harden the configurations.
• The configuration -- including its instance variables names -- is part of a beamline's public API, and it would be nice to be able to write automated integration tests and sphinx documentation against it.
• Moving the configs into one repo increases the visibility of changes, both to DAMA and to the handful of BL staff who take an interest in facility-wide standardization.

I know @stuwilkins has some additional thoughts, related how to users interact with the profiles, but I'm not I could summarize them well, so I'll leave that to him if he has time.

On the other hand, @tacaswell has some strongly-held concerns that I failed to absorb in initial conversations about this. Tom, would you mind spelling them out here?

[CJ-Wright]

I'm mostly on board with this, although I'm not certain how the tests are going to happen since they may be rather beamline specific. I guess we could put the tests into the beamline specific folders under tests?

[stuwilkins]

Ok, I will make some arguments here, I would be very keen to hear thoughts from @tacaswell .

What I like about this is:

• Grouping configuration into a well maintained package apart from in a profile which currently is being very poorly maintained.
• Separating ophyd objects from their instantiation.
• Looking to start a standard set of ophyd devices for NSLS-II standard hardware (shutters / valves) Struck scaler, soft x-ray pgm etc. This will encourage fixing inconsistencies on the floor in PV naming rather than just making another device.
• Pooling together data collecting plans and data beamline specific analysis routines (fast ccd ophyd device along with get_fastccd_images() for example.
• Allowing viewing of other beamline's config/devices from one place to encorage reuse.

Those are what I can think of now... but then I am not sure of the counter view......

[danielballan]

@tacaswell?

[danielballan]

@tacaswell?

[danielballan]

I'll try to get the spirit on @tacaswell's argument:

• Grouping configuration into a well maintained package apart from in a profile which currently is being very poorly maintained.

Yes, but if we move it into one central package, it will become DAMA's job to maintain it.

• Separating ophyd objects from their instantiation.

This is a good idea, but there's no reason we can't do this in the profiles. (See next point...)

• Looking to start a standard set of ophyd devices for NSLS-II standard hardware (shutters / valves) Struck scaler, soft x-ray pgm etc. This will encourage fixing inconsistencies on the floor in PV naming rather than just making another device.

Agreed that many ophyd objects should be moved upstream into either ophyd itself or something like nsls2tools.devices. Some that are still being actively revised might be easier to keep in profiles.

Pooling together data collecting plans and data beamline specific analysis routines (fast ccd ophyd device along with get_fastccd_images() for example.

Agreed that this should be done, too, on a case-by-case basis.

[danielballan]

I think we have a good consensus on this now, which I am documenting over here: NSLS-II/docs#77