Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quickstart Fails: cannot import name 'VERSION_CLASS' #428

Closed
DMPS opened this issue Mar 17, 2021 · 8 comments
Closed

Quickstart Fails: cannot import name 'VERSION_CLASS' #428

DMPS opened this issue Mar 17, 2021 · 8 comments

Comments

@DMPS
Copy link

DMPS commented Mar 17, 2021

Hi Pyscaffold team,

I am trying to bootstrap a new project with PyScaffold using the quickstart here: Pypi. PyScaffold 4.0 installs perfectly fine, but I get the following error when I run putup my_project:

Traceback (most recent call last):
  File "/Users/daltonscott/Library/Python/3.7/bin/putup", line 5, in <module>
    from pyscaffold.cli import run
  File "/Users/daltonscott/Library/Python/3.7/lib/python/site-packages/pyscaffold/cli.py", line 13, in <module>
    from . import api, templates
  File "/Users/daltonscott/Library/Python/3.7/lib/python/site-packages/pyscaffold/api.py", line 9, in <module>
    from . import actions, info
  File "/Users/daltonscott/Library/Python/3.7/lib/python/site-packages/pyscaffold/actions.py", line 20, in <module>
    from . import info, repo
  File "/Users/daltonscott/Library/Python/3.7/lib/python/site-packages/pyscaffold/info.py", line 30, in <module>
    from .templates import ScaffoldOpts, licenses, parse_extensions
  File "/Users/daltonscott/Library/Python/3.7/lib/python/site-packages/pyscaffold/templates/__init__.py", line 14, in <module>
    from .. import dependencies as deps
  File "/Users/daltonscott/Library/Python/3.7/lib/python/site-packages/pyscaffold/dependencies.py", line 9, in <module>
    from setuptools_scm.version import VERSION_CLASS
ImportError: cannot import name 'VERSION_CLASS' from 'setuptools_scm.version' (/Users/daltonscott/Library/Python/3.7/lib/python/site-packages/setuptools_scm/version.py)

What I find most odd, is that I setup a pyscaffold 4.0 project literally last Friday and I did not get any error. Has there been some change in the code since then?

@abravalheri
Copy link
Collaborator

abravalheri commented Mar 17, 2021

Hi @DMPS, this happened because the latest update on setuptools_scm (they just released a new version 5h ago).

While we work on the fix, could you please specifiy setuptools_scm==5.0.2 in your installation for the time being? Probably you would have to change it in the pyproject.toml too (temporarily, while we fix the problem).

@abravalheri
Copy link
Collaborator

@FlorianWilhelm, could we just drop the checks for old versions of setuptools and specify setuptools_scm>=45 as dependency? (This is the minimum version supported by setuptools_scm in v6).

This check was introduced in fc35725 and then moved to the dependencies.py file in v4.
By the time it was introduced the philosophy of PyScaffold was to bundle all the dependencies and be a standalone package. In v4, we changed that. So I wonder as the checking is still necessary...

@FlorianWilhelm
Copy link
Member

@abravalheri, thanks, sounds like a good plan to drop these checks. This should simplify things. We then also need to release version 4.0.1 quite soon, right?

@abravalheri
Copy link
Collaborator

abravalheri commented Mar 17, 2021

Yes.
Since we verified this problem, we actually need to release 4.0.1 asap 😅
Should we cap setuptools_scm version (put a max in the dependency)? It might prevent this bugs to happen, although it will require us to monitor setuptools_scm and bump PyScaffold accordingly...

abravalheri added a commit that referenced this issue Mar 17, 2021
As discussed in #428, some checks we were making for the setuptools
version are incompatible with the latest version of setuptools_scm.

So one alternative (implemented in this PR) is to simply stop verifying
the versions and assume they are satisfied because they are correctly
declared as `install_requires` in `setup.cfg`.

The only doubt left is: what happens if the person is building a
generated project with `--no-pyproject`?

(In `pyproject.toml` we do have a minimum requirement for setuptools,
which is more than enough, but in `setup.py` that is omitted... Should we
add one? Is that a good practice? Or are we just being optimistic and
relying on the error message asking the user to update?)
@drivenbyentropy
Copy link

I am having the same issue and can confirm that adding setuptools_scm==5.0.2 in pyproject.toml for an existing project works. Before that, pip install -e ./ would fail with

  Traceback (most recent call last):
    File "/spin1/home/linux/hoinkaj/repairsig_env/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 280, in <module>
      main()
    File "/spin1/home/linux/hoinkaj/repairsig_env/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 263, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/spin1/home/linux/hoinkaj/repairsig_env/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 114, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 150, in get_requires_for_build_wheel
      config_settings, requirements=['wheel'])
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 130, in _get_build_requires
      self.run_setup()
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 145, in run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 14, in <module>
      setup(use_scm_version=True)
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools/__init__.py", line 153, in setup
      return distutils.core.setup(**attrs)
    File "/usr/local/Anaconda/envs/py3.6/lib/python3.6/distutils/core.py", line 108, in setup
      _setup_distribution = dist = klass(attrs)
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools/dist.py", line 435, in __init__
      k: v for k, v in attrs.items()
    File "/usr/local/Anaconda/envs/py3.6/lib/python3.6/distutils/dist.py", line 281, in __init__
      self.finalize_options()
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools/dist.py", line 743, in finalize_options
      ep(self)
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools/dist.py", line 750, in _finalize_setup_keywords
      ep.load()(self, ep.name, value)
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools_scm/integration.py", line 24, in version_keyword
      dist.metadata.version = _get_version(config)
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 173, in _get_version
      parsed_version = _do_parse(config)
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 127, in _do_parse
      version = _version_from_entrypoints(config) or _version_from_entrypoints(
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 65, in _version_from_entrypoints
      version = _call_entrypoint_fn(root, config, ep.load())
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 46, in _call_entrypoint_fn
      return fn(root, config=config)
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools_scm/git.py", line 124, in parse
      node_date = wd.get_head_date() or date.today()
    File "/tmp/pip-build-env-x8j0ovpl/overlay/lib/python3.6/site-packages/setuptools_scm/git.py", line 64, in get_head_date
      return datetime.strptime(date_part, r"%Y-%m-%d").date()
    File "/usr/local/Anaconda/envs/py3.6/lib/python3.6/_strptime.py", line 565, in _strptime_datetime
      tt, fraction = _strptime(data_string, format)
    File "/usr/local/Anaconda/envs/py3.6/lib/python3.6/_strptime.py", line 362, in _strptime
      (data_string, format))
  ValueError: time data '%cI' does not match format '%Y-%m-%d'
  ----------------------------------------

abravalheri added a commit that referenced this issue Mar 17, 2021
As discussed in #428, some checks we were making for the setuptools
version are incompatible with the latest version of setuptools_scm.

So one alternative (implemented in this PR) is to simply stop verifying
the versions and assume they are satisfied because they are correctly
declared as `install_requires` in `setup.cfg`.

The only doubt left is: what happens if the person is building a
generated project with `--no-pyproject`?

(In `pyproject.toml` we do have a minimum requirement for setuptools,
which is more than enough, but in `setup.py` that is omitted... Should we
add one? Is that a good practice? Or are we just being optimistic and
relying on the error message asking the user to update?)
@abravalheri
Copy link
Collaborator

Thank you very much @drivenbyentropy for confirming the workaround. Hopefully if all the CI checks pass I will release at least an RC candidate today.

@abravalheri
Copy link
Collaborator

New version just released.
It should fix this issue. @DMPS and @drivenbyentropy I will close this ticket because I believe the problem is solved, but please feel free to open it again if you are still having problems after installing the new version.

@drivenbyentropy
Copy link

@abravalheri Fix confirmed. Working like a charm on my end using the new release.

Thanks for the prompt action on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants