microsoft / qsharp

Azure Quantum Development Kit, including the Q# programming language, resource estimator, and Quantum Katas
https://microsoft.github.io/qsharp/
MIT License
456 stars 90 forks source link

Publish more of our written samples to quantum.microsoft.com #1934

Open Manvi-Agrawal opened 1 month ago

Manvi-Agrawal commented 1 month ago

Additional context Creating separate issue from https://github.com/microsoft/qsharp/issues/1709 for better triaging.

sezna commented 4 weeks ago

Yeah, it would probably be good to add more of our written samples to the list of published ones. We are not inclined to use a new repository, though, we moved to a monorepo with the modern QDK (whereas the classic QDK had many repos). But, we don't expect samples to be discovered via browsing this repo. We link straight to the correct directory from our documentation and quantum.microsoft.com.

Manvi-Agrawal commented 4 weeks ago

Yeah, it would probably be good to add more of our written samples to the list of published ones.

Sure, that makes sense. Just to confirm, published samples are primarily sourced from the samples.mjs list, right?

We prefer not to introduce a new repository. We transitioned to a monorepo with the modern QDK (unlike the classic QDK with its many repos).

While I understand the benefits of a monorepo for simplifying build dependencies. But in current structure, I don't see samples outside of 'samples.mjs' list benefitting significantly. For instance, when the @EntryPoint became optional, I recall holding off the sample update unless new version of Azure quantum is released. See https://github.com/microsoft/qsharp/pull/1684#issuecomment-2201166542 for more details.

For samples not in samples.mjs list, I think currently it's useful is for samples testing using Rust code to invoke Q# compiler crate. Probably that can be mitigated by using commit hash, but I did not put too much time thinking into this.

Conceptually speaking, Q# samples should not depend on Q# dependencies. In this case, there seems to be CI/CD dependency. If that's the case, wondering if it highlight a bigger issue regarding usability of Q# language for outside users wanting to verify Q# samples.

However, discovering samples through browsing this repo isn't our main goal. We link directly to the relevant directory from our documentation and quantum.microsoft.com.

Thanks @sezna for the additional context. As far as I'm aware, github.com doesn't currently offer the ability to download a specific folder. Additionally, my attempt to download the samples and samples/algorithms folders from github.dev resulted in an error stating "github.dev can't open folder because it contains system files." While tools might exist for downloading specific folders, I haven't personally used any.

My suggestion for a separate repository stemmed more from simplifying the experience for first-time Q# users. In my opinion, someone new to Q# would be most interested in quick-start samples. A separate repo would also reduce unnecessary data consumption (qsharp repo: ~3.6 GB vs samples folder: ~1MB), which could be a significant factor for users in regions with limited connectivity or bandwidth.