Perhaps have `bug_report()` try to (also) read versions from `pyproject.toml`?

[hugobuddel]

Not sure everything with the versioning actually works as intended. (Intended by us I mean; everything probably works as intended by the tooling.)

See this scenario with a semi fresh ScopeSim clone and semi fresh environment, without ScopeSim installed. Alternating between an empty directory and ScopeSim clone:

Empty directory, as expected:

$ python -c "import scopesim"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'scopesim'

In fresh clone install an old version of ScopeSim. More realistic scenario is installing dev_master now, and then wait a couple of weeks until the versions roll over, so we are mimicking that by explicitly installing something old.

$ git checkout v0.6.2
$ pip install -e .

In empty directory, as expected again::

$ python -c "import scopesim; print(scopesim.__version__)"
0.6.2
$ python -c "import scopesim; print(scopesim.__file__)"
[...]/repos/scopesim/ScopeSim/scopesim/__init__.py
$ python -c "from scopesim.effects.electronic import Quantization"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name 'Quantization' from 'scopesim.effects.electronic' ([...]/repos/scopesim/ScopeSim/scopesim/effects/electronic.py)

These files are installed:

$ find [...]/envs/metiswise2/lib/python3.11/site-packages/ -iname "*scopesim*"
[...]/envs/metiswise2/lib/python3.11/site-packages/__pycache__/__editable___ScopeSim_0_6_2_finder.cpython-311.pyc
[...]/envs/metiswise2/lib/python3.11/site-packages/__editable___ScopeSim_0_6_2_finder.py
[...]/envs/metiswise2/lib/python3.11/site-packages/__editable__.ScopeSim-0.6.2.pth
[...]/envs/metiswise2/lib/python3.11/site-packages/ScopeSim-0.6.2.dist-info

In git clone:

$ git checkout dev_master

In empty directory:

$ python -c "import scopesim; print(scopesim.__version__)"
0.6.2
$ python -c "from scopesim.effects.electronic import Quantization"
# no output
$ python
>>> import scopesim; from pathlib import Path; import toml;
>>> toml.load(Path(scopesim.__file__).parent.parent / "pyproject.toml")['tool']['poetry']['version']
'0.8.0a0'

People are surely going to install ScopeSim in this way.

So maybe we should have bug_report() also try to get the version from pyproject.toml?

Originally posted by @hugobuddel in https://github.com/AstarVienna/ScopeSim/issues/355#issuecomment-1923395094

[teutoburg]

Just to make sure I understand what the issue is here: So this happens if someone

1. Clones ScopeSim (or done that previously)
2. Does a local pip install
3. Then pulls a more recent version
4. But doesn't install again

Is that correct?

[hugobuddel]

Yeah... That's probably abuse of -e. Because many other things could have changed that would require installing it again.

I usually just checkout a different branch when I want to compare different versions, without actually installing it again. This usually works, because earlier versions still work with newer dependencies.

In the past we had the version defined in version.py, so we would always get that version irrespective of how things are installed. So it is kinda a regression. But maybe not worth it to do anything about this.

Maybe an editable install is a bad idea to begin with. But the option of editable installs is perhaps also an attractive part of interpreted languages.

[teutoburg]

Hmmmm. Well I guess I wouldn't hurt to additionally toml.load the versions for the bug_report and maybe put them next to the one obtained from importlib.metadata.version, this might help us diagnose things.

[hugobuddel]

But where does it stop? Using pip install gitpython, this is also interesting information:

>>> git.Repo(Path(scopesim.__file__).parent.parent).head.object.hexsha
'7cfe1f51f0de96797d04131ab492a4411fa530b8'

and then of course also whether it is dirty or not, etc.

That might be more informative than what is in pyproject.toml. Because the original issue is only relevant if there is an editable install, and an editable install is ~only interesting if there is a git checkout, and then the commit hash is more useful than the version.

So not sure it is worth it. Probably not