Hi Jonathan Sick, since this is a structural change to `lsst.verify`, can you take a look and confirm that this won't cause any non-obvious trouble?

If you're going to the trouble of renaming this, I'll be honest and say that the name is still obscure. Could you consider making the namespace of this compatibility layer lsst.verify.gen2tasks and then when things are working in Gen3 the namespace is `lsst.verify.tasks`?

I think having those two parallel namespaces might make the transition easier to understand as well. And yes, as far I as understand that'd mean moving python/lsst/verify/metricTask.py to python/lsst/verify/tasks/metricTask and making APIs available from that namespace (e.g. lsst.verify.tasks.MetricComputationError).

This has all the advantages of the verify_measurements plan you originally proposed, without the unnecessary overhead of creating a new EUPS package.

No objections to gen2tasks.

As for tasks, didn't you say that the code should live in the lsst.verify namespace (I thought there were technical reasons why it mattered, but I can't find mention of them now)? Or are you saying that the tasks package should not get imported into verify proper?

I guess it's a judgement call, and we could go either way. If, after doing the compatibility subpackage work, you like that all the task framework stuff is in a namespace, then you could by all means have a lsst.verify.tasks namespace for the final implementation. Putting all the public APIs in lsst.verify would also be fine. I'll leave that up to you.

I think my original concern was mostly against having an extra EUPS package. Mostly I just want the pipeline interface and the primitives to be documented and developed in the same place.

All that said, I do love the simplicity of something like "from lsst.verify import MetricTask" so if we can still do that, forget everything I said about lsst.verify.tasks

Ok then, I've renamed compatibility to gen2tasks but am keeping the gen 3-compatible APIs in lsst.verify. Can you take another look?

LGTM