Added section for contributing to Magics

[Manvi-Agrawal]

This is as per the following comments : #166 (comment), #166 (comment) and #166 (comment)

[Manvi-Agrawal]

Hi @tcNickolas. Changed the instructions in Contributing Guide a bit to avoid skipping the auto-loading of projects by IQ# kernel. I think this is a slightly better technique to test the changes locally since the end goal is to ensure IQ# is successfully auto-loading the projects. Also, this technique allows to manipulate cache assembly in a bit more convenient way from the KataMagic and CheckKataMagic, should we decide to do in future.

[tcNickolas]

I did a quick pass, I still have to try these steps myself to make sure they work, but I left some comments independently of that.

Thank you!

[Manvi-Agrawal]

Hi @tcNickolas. I have made the desired changes.

And as for this one :

Do we need this line, or would it work if we just change the version in the <PackageReference Include="Microsoft.Quantum.Katas" Version="0.16.2104138035" /> dependency in the .csproj file? Trying to figure out how to minimize the number of steps.

I initially tried that approach only but the IQ# kernel for no particular reason loaded the katas package of the same version as the IQ# kernel. I think this might be due to the fact that IQ# kernel would attempt to load dependencies of the same version as the kernel if IQSharpLoadAutomatically is set to true.

[Manvi-Agrawal]

Hi @tcNickolas . I noticed a strange phenomenon after qdk-update to the the version 0.16.2104138035

if we do the following in NuGet.config as per step 2.3

<add key="Local Folder" value="." />

• In the version 0.16.2104138035
  Custom nuget now needs to be placed in the QuantumKatas folder(ie the same folder as that of NuGet.config file)

• With early versions : 0.15.2101125897 and 0.15.2103133969
  We needed to move the generated nuget to the project in which the project resided.

Maybe @rmshaffer could help in confirming if changes in IQ# kernel are done or there is some problem with my local :-(

[tcNickolas]

Sadly, Ryan is no longer with our team, so @anjbur is picking up IQ# ownership.
@anjbur, were there any changes that could cause this behavior change in the past month?

Generally I would suggest recommending the person working with the custom Microsoft.Quantum.Katas package to put both NuGet.config and the custom package to the folder of the project they're using as a test, rather than in folders closer to root. That's what I do myself, to limit the scope of the custom settings and to make it harder to get unintended consequences when working with other katas.

[Manvi-Agrawal]

@tcNickolas @anjbur Apologies for the confusion caused due to the previous comment. Initially when I was following step 3 as mentioned here, I changed the NuGet.config file present in the root folder of the QuantumKatas and added <add key="Local Folder value="." /> and things seemed to go pretty well in 0.15.2101125897 and 0.15.2103133969 until the next Qdk-update to version 0.16.2104138035.

As of now, these instructions work perfectly on my local machine. One edge-case was left about someone attempting to run the validate notebook script for the first time after creating the custom package, hence I added it as well. Would love to know if these instructions work well on your machine.

[tcNickolas]

I finally got the time to sit down and go through all the debug steps - they look great, I think the only thing I didn't need was the root namespace. I did a bit of editing to call out some things that got me confused (for example, that removing package reference to M.Q.Katas will break the build but that's ok).

Thank you!