[AGIPD][CORRECT] Clean up before AGIPD calcalt_interface changes

These are small changes that I thought of adding before updating the notebooks for calcat_interface changes.

Related to https://git.xfel.eu/calibration/planning/-/issues/150

Description

1. Replace use_dir_creation_date with the possibility of adding a creation_time
2. Remove overwrite flag.
3. Remove unused flags and imports.
4. Import only the needed functions and methods from cal_tools modules.
5. Replace get_dir_creation_date with calcat_creation_time
6. Remove the flags hinting at the possibility to use local dark constants.
7. Remove the calfile flag.

How Has This Been Tested?

Relevant Documents (optional)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (refactoring code with no functionality changes)

Checklist:

Reviewers

added 1 commit

• 8e4cd0ef - warning instead of warn and some refactors

Compare with previous version

changed title from clean ups before AGIPD calcalt_interface changes to [AGIPD][CORRECT] Clean up before AGIPD calcalt_interface changes

assigned to @ahmedk

mentioned in merge request !774 (merged)

changed the description

added New CALCAT interface Waiting for review labels

changed the description

In hindsight I wonder now, should we use from warnings import warn or from logging import warning? For the latter, my prototype used logging.captureWarnings. It would have the additional benefit we capture "other" warnings as well.

@kluyvert Are you aware of a canonical opinion on this one?

The Python logging howto suggests:

warnings.warn() in library code if the issue is avoidable and the client application should be modified to eliminate the warning

logging.warning() if there is nothing the client application can do about the situation, but the event should still be noted

People don't exactly agree on this, though.

From a practical perspective, the warnings module offers some possibilities that logging doesn't, like turning warnings into exceptions or displaying only the first instance of each warning. And warnings are visible by default, whereas logging has to be set up to show anything. But if you're using the logging framework anyway, then log.warning() associates them with a particular logger (normally associated with a module), which allows for better filtering.

From the Python logging howto, indeed logging.warning seems to be the right choice. I'm not yet sure we can make use of multiple loggers given for notebooks, it'll be set up magically and they're using the default logger anyway (or the warning one if we'd use warnings.warn()). But heck, in the end as long as the handler supports multiple loggers, it doesn't even matter.

Thanks, LGTM. Don't hold it off for the philosophical question I asked about warnings.

changed milestone to %3.8.0

Thank you for the review!

merged

mentioned in commit 1c5290cc