Templater upgrade [unitaryHACK]

[andre-a-alves]

Closes #52 In the end, this templater does not do ALL the things I initially set out to accomplish, but it does quite a bit more than you had before.

1. Everything has defaults, so you can just keep hitting enter and it will build you a 3-host network.
2. It generates any of the topologies that are pre-programmed.
3. You can choose from the available back ends.
4. You can name all the nodes whatever you would like.
5. The sample protocols are copied from the example eavesdropping protocol in the documentation.

Where this falls short:

1. I wrote the eavesdropping options in, but they are commented out. The code from the eavesdropping example does not work, and it would take a lot of digging to figure out what needs to be changed. This is a separate issue, but it is easy to add the functionality into here in the future.
2. After the issue with the non-functional eavesdropper, I was reluctant to write the EPR/GHZ portions. If the code is functional, I could easily add that in the future, though.
3. There are no unit tests. I tested everything by hand, but being a procedural program that takes inputs everywhere and not an OOP program, I think that might be ok.
4. Network topologies cannot yet be fully customized.

I do have follow-up questions after this PR:

1. Between this templater and the scope generate_topology will reach once it's complete, might it be a good idea to create a NetworkFactory class that generates new networks? If that existed, it would encompass most of the functionality in this templater and it could encompass the topology generation functions.
2. I saw in the 18 April notes that you posted on Discord that this may be moving away from Python. If so, do you know which language it will migrate to? I ask because even though I found this project through Unitary Hack, I have a bit of a background in networking and I am very interested in quantum information science, so I plan to keep steadily contributing if you'll accept the help. But right now I think I lack an overall vision for the direction the project is eventually destined for.

If you want to discuss any of this in a more comfortable setting than GitHub comments, feel free to reach out to me on the Unitary Fund Discord server.

[stephendiadamo]

Thanks for the PR. I'll review it shortly.

I wrote the eavesdropping options in, but they are commented out. The code from the eavesdropping example does not work, and it would take a lot of digging to figure out what needs to be changed. This is a separate issue, but it is easy to add the functionality into here in the future.

Regarding the eavesdropping, I think we may have changed the method names. Especially the example in our documentation is outdated and needs an update. There's another example with eavesdropping that is correct, but I think this feature needs test cases for sure.

After the issue with the non-functional eavesdropper, I was reluctant to write the EPR/GHZ portions. If the code is functional, I could easily add that in the future, though.

EPR generation is independent of eavesdropping, so the outdated eavesdropper shouldn't prevent that part. Especially there are automated test cases for EPR / GHZ generation.

There are no unit tests. I tested everything by hand, but being a procedural program that takes inputs everywhere and not an OOP program, I think that might be ok.

That's fine. I'll also test it.

Between this templater and the scope generate_topology will reach once it's complete, might it be a good idea to create a NetworkFactory class that generates new networks? If that existed, it would encompass most of the functionality in this templater and it could encompass the topology generation functions.

That sounds like a good idea. I guess the Network class will quickly become a really large class if we put all the features in.

I saw in the 18 April notes that you posted on Discord that this may be moving away from Python. If so, do you know which language it will migrate to?

At the moment it was just a thought, there's no progress towards migrating QuNetSim. I was thinking mainly, if we want to target performance then moving off of Python to C or something might be the way to go for that.

I have a bit of a background in networking and I am very interested in quantum information science, so I plan to keep steadily contributing if you'll accept the help

That would be great! We can discuss more in the coming days/weeks.

[stephendiadamo]

I guess this PR needs to be re-merged to be aligned with topology PR, as now there are merge conflicts. Would you like to resolve them @andre-a-alves? I can do it also, but you know the code better.

[andre-a-alves]

Sure thing. I'll take care of it this evening.

[stephendiadamo]

I made some small changes and opened PR #105 with the updates. I'll close this one and merge the other.