quantumlib
conda-forge package?
Hi, A while ago (https://github.com/quantumlib/OpenFermion/pull/376#pullrequestreview-131830920) you preferred conda packages of openfermion to remain on the psi4 channel. That's worked nicely so far through v0.11. I just finished packaging v1.0 and ended up needing to package cirq and @jcmgray's quimb, too. Users of the psi4 channel probably aren't the target audience for any of those. Also, psi4 is defaults-channel-based, while some of the latest packaging round needed conda-forge packages (pyquil, autoray). (I haven't taken a close look at runtime vs. testing-time deps yet.) I wondered if you had thought differently since about packaging with conda-forge? No pressure, and feel free to close if you don't think c-f a useful venue for openfermion. Thanks for keeping up the psi4 interface!
For what its worth quimb should be very easy to package to conda-forge, and I plan to - just haven't got round to it yet..
pyquil and quimb also aren't part of the main requirements of cirq (they're part of an optional set of dependencies we call "contrib").
We should have a cirq conda-forge package, though @balopat
pyquil and quimb also aren't part of the main requirements of cirq (they're part of an optional set of dependencies we call "contrib").
Is there any way to run tests without these optional dependencies? That's where I'm hitting trouble building and testing a non-contrib cirq package?
It should work as long as you don't run the contrib tests, for example
pytest --ignore=cirq/contrib
from the source directory.
For the conda package, you can probably just get away with testing that import cirq works in the conda recipe and rely on the unit tests being run by our CI. Don't know what your opinion of this strategy is
pytest --ignore=cirq/contrib
Thank you, but the difficulty is that the optional contrib packages are imported at tests collection time, not just run time.
For the conda package, you can probably just get away with testing that import cirq works in the conda recipe and rely on the unit tests being run by our CI. Don't know what your opinion of this strategy is
Skipping tests for cirq is ok by me for the psi4 channel, which is what I've done. For conda-forge, they strongly encourage tests. Would import availability guards be reasonable?
oh that's really annoying.
I think import tests will get us most of the way there. I would think conda-forge doesn't want their infrastructure tied up running cirq tests? https://conda-forge.org/docs/maintainer/adding_pkgs.html#test says it should be fine
I also found https://stackoverflow.com/a/57003743 if you still want to try to get the test to run without contrib