Add interfaces from QEDprocesses.jl

[AntonReinhard]

No description provided.

[AntonReinhard]

Doctests now fail because some of them use functionality that is now in QEDcore. I think the doctests are still useful, is there an easy way to make QEDcore available for the doctests too, similar to the package extensions for the tests?

[AntonReinhard]

Most of the tests have moved to QEDcore for now.

[szabo137]

Doctests now fail because some of them use functionality that is now in QEDcore. I think the doctests are still useful, is there an easy way to make QEDcore available for the doctests too, similar to the package extensions for the tests?

IMHO, the base_state function is not an interface function and can be moved entirely to QEDcore. There, the doctests should work.

I think the same is true for the propagator function.

[AntonReinhard]

Doctests now fail because some of them use functionality that is now in QEDcore. I think the doctests are still useful, is there an easy way to make QEDcore available for the doctests too, similar to the package extensions for the tests?

IMHO, the base_state function is not an interface function and can be moved entirely to QEDcore. There, the doctests should work.

I think the same is true for the propagator function.

I disagree actually. They are useful functions that can be used for multiple purposes and are overloaded on the specific implementations of the ParticleTypes. For example, they're required in the metagraph optimization project, and if we want to make QEDcore replaceable by an alternative implementation (at least in theory), then propagator and base_state should stay in QEDbase as interfaces that need to be implemented.

[szabo137]

Doctests now fail because some of them use functionality that is now in QEDcore. I think the doctests are still useful, is there an easy way to make QEDcore available for the doctests too, similar to the package extensions for the tests?

IMHO, the base_state function is not an interface function and can be moved entirely to QEDcore. There, the doctests should work.
I think the same is true for the propagator function.

I disagree actually. They are useful functions that can be used for multiple purposes and are overloaded on the specific implementations of the ParticleTypes. For example, they're required in the metagraph optimization project, and if we want to make QEDcore replaceable by an alternative implementation (at least in theory), then propagator and base_state should stay in QEDbase as interfaces that need to be implemented.

Ok, I revoke my statement about base_state and propagator. Since these are needed for every particle anyway, they must be part of the particle interface.

[szabo137]

Seems like the integration test for QEDevents sill breaks, because in there QEDevents.jl is precompiled against the registered version of QEDprocesses.jl and not against QEDprocesses.jl#dev. An obvious solution might be, just releasing QEDprocesses.jl either to general as 0.2.0 or to the local registry (as 0.1.1-DEV). I think the latter is favorable because it does not release and unfinished version of QEDprocesses.jl.

What do you think?

Edit: I opened QEDjl-project/QuantumElectrodynamics.jl#36 to eventually update the integration tests to address these situations. But this is not relevant for this one.

[AntonReinhard]

Seems like the integration test for QEDevents sill breaks, because in there QEDevents.jl is precompiled against the registered version of QEDprocesses.jl and not against QEDprocesses.jl#dev. An obvious solution might be, just releasing QEDprocesses.jl either to general as 0.2.0 or to the local registry (as 0.1.1-DEV). I think the latter is favorable because it does not release and unfinished version of QEDprocesses.jl.

What do you think?

Yes sounds good. I wouldn't release publicly at this state, so local registry seems like the way to go.

[AntonReinhard]

Testing QEDjl-project/QEDcore.jl#25 with this branch works for me locally, so the two should be good to merge together.

[szabo137]

Very good work! Thanks for the movement. We need to refactor the tests of the interfaces at some point. Maybe another issue to be opened 😅

[szabo137]

All conversations are resolved. No concerns from my side. Let the merge begin!