Error when installing dependencies for new Windows Machine.

[dgmouris]

Describe the bug

When getting set up as a developer I get an error if I'm not on a version that is tagged.

Steps to reproduce

1. Go to 'create empty virtualenv'
2. Run pip install -e ./core[dev] -e ./dummy -e ./winforms
   The following output is what I see.

$ pip install -e ./core[dev] -e ./dummy -e ./winforms
Obtaining file:///C:/Users/dmouris/beeware/toga/core
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build editable ... error
  error: subprocess-exited-with-error

  × Getting requirements to build editable did not run successfully.
  │ exit code: 1
  ╰─> [46 lines of output]
      Traceback (most recent call last):
        File "C:\Users\dmouris\beeware\toga\venv\Lib\site-packages\pip\_vendor\pep517\in_process\_in_process.py", line 351, in <module>
          main()
        File "C:\Users\dmouris\beeware\toga\venv\Lib\site-packages\pip\_vendor\pep517\in_process\_in_process.py", line 333, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\beeware\toga\venv\Lib\site-packages\pip\_vendor\pep517\in_process\_in_process.py", line 132, in get_requires_for_build_editable
          return hook(config_settings)
                 ^^^^^^^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools\build_meta.py", line 447, in get_requires_for_build_editable
          return self.get_requires_for_build_wheel(config_settings)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools\build_meta.py", line 338, in get_requires_for_build_wheel
          return self._get_build_requires(config_settings, requirements=['wheel'])
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools\build_meta.py", line 320, in _get_build_requires
          self.run_setup()
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools\build_meta.py", line 335, in run_setup
          exec(code, locals())
        File "<string>", line 5, in <module>
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools_scm\__init__.py", line 147, in get_version
          maybe_version = _get_version(config)
                          ^^^^^^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools_scm\__init__.py", line 157, in _get_version
          version_string = format_version(
                           ^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools_scm\version.py", line 554, in format_version
          main_version = _call_version_scheme(
                         ^^^^^^^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools_scm\version.py", line 542, in _call_version_scheme
          result = scheme(version)
                   ^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools_scm\version.py", line 296, in guess_next_dev_version
          return version.format_next_version(guess_next_version)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools_scm\version.py", line 192, in format_next_version
          guessed = guess_next(self, *k, **kw)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools_scm\version.py", line 244, in guess_next_version
          return _bump_dev(version) or _bump_regex(version)
                 ^^^^^^^^^^^^^^^^^^
        File "C:\Users\dmouris\AppData\Local\Temp\pip-build-env-7l5qbv6b\overlay\Lib\site-packages\setuptools_scm\version.py", line 271, in _bump_dev
          raise ValueError(
      ValueError: choosing custom numbers for the `.devX` distance is not supported.
       The 0.3.0.dev23 can't be bumped
      Please drop the tag or create a new supported one ending in .dev0
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

× Getting requirements to build editable did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

[notice] A new release of pip available: 22.3.1 -> 23.2.1
[notice] To update, run: python.exe -m pip install --upgrade pip

Expected behavior

It should just install without an issue.
Fixed with the following steps.

1. Add the remote to toga git remote add upstream git@github.com:beeware/toga.git
2. Fetch all the tags git fetch --all --tags
3. Go to any tag that doesn't have "dev" in the name.
4. install the dependencies.

Screenshots

No response

Environment

• Operating System: Windows 10
• Python version: 3.11.3
• Software versions:
  • Toga: v0.3.1 (to the most recent commit)

Logs

Additional context

No response

[mhsmith]

Toga now uses setuptools-scm to automatically generate version numbers from Git tags. So you don't need to be on a tagged version, but you do need to have pulled all the tags.

My guess is that you cloned the repository some time ago, and haven't pulled the tags since. In which case, the only thing you actually needed to do is git fetch --all --tags.

[freakboy3742]

Even though it's not going to affect that many people, it's a non-obvious failure mode, so it's probably worth a mention in the contribution docs.

[dgmouris]

@mhsmith @freakboy3742 thank you for your responses. I just thought it might help someone out:)

[rmartin16]

This was the same problem I was having once the setuptools_scm implementation was merged. And different forms of this problem continued to manifest until I completely changed how I manage my local repos.

Based on the contributing guide, users should clone their forked copy of the repo. This initial action should fork the repo with all the tags. However, over time, this becomes out of date unless the user manually manages the tags in their fork....or they add beeware/toga as a remote and manually fetches the tags from this new remote. (Although, then the user's GitHub fork becomes out of date unless they then push the tags back up.)

I got around all this by first cloning beeware/toga such that it's the origin remote. I, then, add my own fork as a remote named rmartin16 (and do this for repos with branches I want to test). Finally, I update pushurl in .git/config so pushes from this repo go to my fork instead of beeware/toga.

[remote "origin"]
	url = git@github.com:beeware/toga.git
	fetch = +refs/heads/*:refs/remotes/origin/*
	pushurl = git@github.com:rmartin16/toga.git

In this way, IMHO, I'm more reliably using beeware/toga as the source of truth for versioning since a git pull main pulls from main on beeware/toga instead of rmartin16/toga.

I'm feel like I may be missing something with using my own fork as the origin remote....or this "git tag dance" is just what's required.

Insight on how others are handling this is appreciated....I can probably submit a doc update once I understand the way users are supposed to manage this....without being a git wizard...