Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

restructure #154

Open
nataliejpg opened this issue Nov 30, 2018 · 2 comments
Open

restructure #154

nataliejpg opened this issue Nov 30, 2018 · 2 comments

Comments

@nataliejpg
Copy link
Collaborator

nataliejpg commented Nov 30, 2018

How do people feel about restructuring the repository? I know that this by default is pretty annoying but I think it would be a lot easier to use and save a lot of headache later. My ideas are

  • subfolders in the customised_instruments folder by name of the instrument manufacturer or user defined name, this would mirror the qcodes structure and is useful for cases of multiple customised channels which belong to one instrument or similar.
  • a folder for customised_parameters where customised parameters live, the argument against this is that they might be very specific and only work with a particular (customised) instruments and might be better grouped with them
  • put the alazar_controller folder inside customised instruments (and pull out the parameters to live in customised_parameters if we go ahead with that).
  • delete the subgroup folders (transmon, majorana, spinqubit). If anyone is still using anything from them then it makes more sense to refactor it into somewhere existing or think of a new place to put it named based on functionality rather than the name of the subgroup expected to use it...

@jenshnielsen @WilliamHPNielsen @ThorvaldLarsen

@ThorvaldLarsen
Copy link
Collaborator

this sounds good to me. Only thing that confuses me is:

a folder for customised_parameters where customised parameters live, the argument against this is that they might be very specific and only work with a particular (customised) instruments and might be better grouped with them

How come customized parameters are not living inside the extended instrument driver? Seems a bit excessive to separate out into a new folder.

@nataliejpg
Copy link
Collaborator Author

@ThorvaldLarsen I think that is the other natural place for them. This would work well for those of them that are very instrument specific and can then live in the same folder as the instruments they are attached to but some customised parameters will be quite general and might be useful across instruments. Having a customised_parameters folder would make more sense for these ones (but less sense for the instrument specific ones). It seems unlikely to me to find something that suits both of these cases very well. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants