Project references

[cgranade]

Is your feature request related to a problem? Please describe.
Similar to the current %package magic in IQ# (exposed as qsharp.packages in the Python client), it would be nice to have a %project magic that adds a reference to a .csproj file containing Q# code.
This would make it easier to use Visual Studio or Visual Studio Code intelliSense features with Python hosts by providing the appropriate information to the language server about Q# compilation units.
This feature would also make it easier to package Q# code along with Python hosts without having to depend on assumptions about the current working directory.

Describe the solution you'd like
A magic command of the form %project ../path/to/project.csproj would cause the following to occur:

• project.csproj would be added as a project reference to the current IQ# session.
• If project.csproj is not up to date, it would be rebuilt and its build artifact (assembly) added as a reference to all future snippets.
• Upon %workspace reload, referenced projects would be rebuilt if out-of-date.

[glassnotes]

Are there any updates on this functionality? It would be very helpful for testing to be able to use Python/Jupyter notebooks during the development process. Thanks!

[rmshaffer]

@glassnotes this is still very much on the radar, just not something we've found time to do yet.

Note that you can already use Python/Jupyter notebooks to develop with Q#. Currently all of your .qs source files must live in the same folder as the .py/.ipynb file you're working with. When loading the IQ# kernel (i.e., either when starting a Q# notebook, or running import qsharp from Python), the operations/functions in these .qs files are automatically made available for use. If you are actively changing the source files, you can use %workspace reload in Jupyter or qsharp.reload() in Python to force recompilation.

[crazy4pi314]

So if I can add some more context to what @glassnotes was was saying we are working on developing a library for Q# here: qRAM.

For nuget packaging purposes, we have the source for the library in a separate directory from the samples which is what @glassnotes was working on at the time. We can use the %package command and adding a custom nuget feed for our GitHub published nuget package (will go to nuget.org once closer to finished) but then if you are debugging or working on the library you have to push a new packaged version to be able to use it from Python. I don't think having it in the same folder is really a solution that will work here, so in the meantime, I have written a C# host that can have the project reference. I would much rather do it in Python as we want to use it to generate the testing data/plot results but I also don't want to keep forgetting that I have to re-publish the library to use it from %package.

Basically tl;dr it would be nice to have feature parity between using Python as a host and using a C# host as most of my academic colleagues use Python.

[crazy4pi314]

Woooo this is On Deck!!! 💖💖💖

[rmshaffer]

Woooo this is On Deck!!! 💖💖💖

@crazy4pi314, glad you're excited about it! I've put some details about the proposed implementation in the initial PR #233. Any feedback or suggestions are more than welcome, either here or in the PR.