pip install <qiskit/cirq>-superstaq on Windows

[vietphamngoc]

What is happening?

The installation of <qiskit/cirq>-superstaq on Windows throws the following error:

File "C:\Users\viet.phamngoc\AppData\Local\Temp\pip-build-env-k7mfbk84\overlay\Lib\site-packages\setuptools\config\expand.py", line 215, in _load_spec
          spec.loader.exec_module(module)  # type: ignore
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "<frozen importlib._bootstrap_external>", line 936, in exec_module
        File "<frozen importlib._bootstrap_external>", line 1074, in get_code
        File "<frozen importlib._bootstrap_external>", line 1004, in source_to_code
        File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
        File "C:\Users\viet.phamngoc\client-superstaq\qiskit-superstaq\qiskit_superstaq\_version.py", line 1
          ../../general-superstaq/general_superstaq/_version.py
          ^
      SyntaxError: invalid syntax

How can we reproduce the issue?

conda create -n venv-qiskitsuperstaq python=3.11
conda activate venv-qiskitsuperstaq
cd client-superstaq
cd qiskit-superstaq
pip install -e ".[dev]"

What should happen?

pip install should pass without error. Seems to be working on Linux

Environment

• Superstaq version:
• general-superstaq version:
• cirq-superstaq version:
• qiskit-superstaq version:
• Operating system: Windows 10 Pro
• Python version:
• Any other relevant dependencies:

Any additional context?

No response

[dowusu-antwi]

(@vietphamngoc discovered while we onboarded)

[dowusu-antwi]

We might be forgetting to use os.path.normpath somewhere? Like in

client-superstaq/checks-superstaq/checks_superstaq/check_utils.py

Line 403 in 768943b

globs.append(os.path.normpath(os.path.join(os.path.relpath(glob, start=root_dir), "*")))

[richrines1]

it looks like it's failing to import because (qiskit|cirq)_superstaq/_version.py are symlinks to general_superstaq/_version.py, which only work on windows with the linux subsystem (which we should probably make more clear in our docs..)

[dowusu-antwi]

it looks like it's failing to import because (qiskit|cirq)_superstaq/_version.py are symlinks to general_superstaq/_version.py, which only work on windows with the linux subsystem (which we should probably make more clear in our docs..)

👍 @vietphamngoc https://learn.microsoft.com/en-us/windows/wsl/

@richrines1 it's probably sufficient to mention WSL in the readme.

[vietphamngoc]

It looks like replacing ../../general-superstaq/general_superstaq/_version.py in <qiskit|cirq>_superstaq/_version.py
with: exec(open("../general-superstaq/general_superstaq/_version.py").read()) also does the trick without WSL.

[vietphamngoc]

It looks like replacing ../../general-superstaq/general_superstaq/_version.py in <qiskit|cirq>_superstaq/_version.py with: exec(open("../general-superstaq/general_superstaq/_version.py").read()) also does the trick without WSL.

Managed to install qiskit-superstack without WSL with this change.

[richrines1]

replacing ../../general-superstaq/general_superstaq/_version.py in <qiskit|cirq>_superstaq/_version.py with: exec(open("../general-superstaq/general_superstaq/_version.py").read())

this is fine locally but unfortunately won't work when deploying to/installing from pypi, where (1) the directory structure won't be consistent, and (2) each package needs to have its own independent version (in principle i could e.g. install gss v0.5.5 alongside css v0.5.4, in which case css.__version__ should be different from gss.__version__). the symlinks work because they get converted to hard copies when building a wheel to deploy

if we need to we could replace the symlinks with hard copies, it just creates a bit more work for us when upgrading/etc. how important is it to work without the wsl? do all the tests pass without it (after your change)?

[vietphamngoc]

I couldn't run the tests without wsl and it's definitely not worth the hassle of changing everything.
Sorry for the inconvenience.

[richrines1]

Sorry for the inconvenience

not an inconvenience! it's a good question, ideally we'd be more platform-agnostic - it's just not something we've had time/reason to prioritize as of yet