Branch pruning

[pennylaneai]

Branch pruning

[cgogolin]

I will do all of that tomorrow on my Xanadu day.

[cgogolin]

What about the old plugins branch? That can be deleted as well, no?

[co9olguy]

Can everyone take a look over all the branches they are responsible for and delete them if they have served their purpose? If any branches need to be merged, discuss it here.

This will help everyone more easily keep track of the current repository status

[co9olguy]

merged new_intro into master and removed remote tracking branch with af14a14. There is still some work to do on the documentation here, but the new Introduction section is done

[cgogolin]

Deleted:

• build_system: Deleted. I was hoping that this would motivate someone to continue with this, as having a decent make file will make us all more efficient in the long run...
• parameter_pass_on: Deleted because it is obsolete now that we are changing the API completely. These changes were necessary to get the ProjectQ plugin to run with the old API. I will open an issue so that a replacement for these changes gets implemented in the new API.
• projectQ_plugin Deleted because it has become obsolete due to the redesign of the API.
• new_user_interface_pseudo_code_exampple_christian: Deleted. This was just to host the pseudo code.

Still relevant:

• new_user_interface_suggested_minor_improvements: It doesn't look like the changes here were actually merged (see my new pull request #15). I think these are actually important changes. Without some of them I cannot even run some of the examples after installing OpenQML (I get errors about openqml.expectation not being found. It works as long as one runs the examples without installing) and it solves the issue that all plugins (with all their potentially huge dependencies) are loaded every time one imports OpenQML. Only the plugins that are actually to be used in a given program should be loaded. This was discussed with Josh (who proposed the fix implemented in this branch).

[co9olguy]

@cgogolin: can we add the makefile to master?
@josh146: thoughts on PR #15?

[smite]

I merged cv_gradients to master and deleted it.

[cgogolin]

Feel free to add the makefile to master. I didn't feel I had the authority to do that, plus the current makefile in the branch was still very limited in functionality. Probably it would be best if the person who designed the build system for SF would take this into her/his hands.

[josh146]

With regards to the makefile, I have copied over all the makefiles and python packaging boilerplate from SF, and set it up in the new_user_interface branch, so I think I would prefer we use those in the eventual master

[cgogolin]

Good. That's perfect.

[josh146]

Also, with regards to #15, I actually implemented them manually while talking to @cgogolin on Slack, but forgot to push! I pushed them yesterday, however.

[cgogolin]

I think this can be closed.