setuptools_scm icon indicating copy to clipboard operation
setuptools_scm copied to clipboard

LookupError: setuptools-scm was unable to detect version for '/tmp'

Open radugrosu opened this issue 5 years ago • 13 comments

I'm using the following namespace-package structure (the namespace is in this example nametest):

root
├── name-common
│   ├── nametest
│   │   ├── metrics.py
│   │   └── utils.py
│   ├── requirements.txt
│   └── setup.py
├── name-serve
│   ├── nametest
│   │   └── serve
│   │       ├── __init__.py
│   │       └── selector.py
│   ├── requirements.txt
│   └── setup.py
└── setup.py

The full error message when doing pip install . in any of name-common or name-serve is:

    ERROR: Command errored out with exit status 1:
     command: /home/radu/bin/anaconda3/envs/aimtest/bin/python -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-req-build-cx0dk49_/setup.py'"'"'; __file__='"'"'/tmp/pip-req-build-cx0dk49_/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base pip-egg-info
         cwd: /tmp/pip-req-build-cx0dk49_/
    Complete output (25 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-req-build-cx0dk49_/setup.py", line 11, in <module>
        packages=find_namespace_packages(include=['nametest.*'], exclude=['tests']),
      File "/home/radu/bin/anaconda3/envs/aimtest/lib/python3.6/site-packages/setuptools/__init__.py", line 145, in setup
        return distutils.core.setup(**attrs)
      File "/home/radu/bin/anaconda3/envs/aimtest/lib/python3.6/distutils/core.py", line 108, in setup
        _setup_distribution = dist = klass(attrs)
      File "/home/radu/bin/anaconda3/envs/aimtest/lib/python3.6/site-packages/setuptools/dist.py", line 446, in __init__
        k: v for k, v in attrs.items()
      File "/home/radu/bin/anaconda3/envs/aimtest/lib/python3.6/distutils/dist.py", line 281, in __init__
        self.finalize_options()
      File "/home/radu/bin/anaconda3/envs/aimtest/lib/python3.6/site-packages/setuptools/dist.py", line 734, in finalize_options
        ep.load()(self, ep.name, value)
      File "/home/radu/bin/anaconda3/envs/aimtest/lib/python3.6/site-packages/setuptools_scm/integration.py", line 17, in version_keyword
        dist.metadata.version = get_version(**value)
      File "/home/radu/bin/anaconda3/envs/aimtest/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 150, in get_version
        parsed_version = _do_parse(config)
      File "/home/radu/bin/anaconda3/envs/aimtest/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 113, in _do_parse
        "use git+https://github.com/user/proj.git#egg=proj" % config.absolute_root
    LookupError: setuptools-scm was unable to detect version for '/tmp'.
    
    Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.
    
    For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

The contents of setup.py are:

from setuptools import setup, find_namespace_packages


setup(
    name='name.common',
    use_scm_version={"root": "..", "relative_to": __file__},
    setup_requires=['setuptools_scm'],
    packages=find_namespace_packages(include=['nametest.*'], exclude=['tests']),
)

When running pip install -e . everything works fine. I'm not sure how to get around this, would appreciate any input. Thanks.

radugrosu avatar Sep 06 '19 20:09 radugrosu

This relates to pip copying around things without nice access to required Metadata, a conversation with the pip developers has been started, but it is not close to any conclusion

RonnyPfannschmidt avatar Sep 07 '19 19:09 RonnyPfannschmidt

@RonnyPfannschmidt Is this discussion public anywhere?

xhochy avatar Sep 19 '19 12:09 xhochy

This relates to pip copying around things without nice access to required Metadata,

Is it really? I had the same error message and it was because I by mistake was using use_scm_version={"root": "..", "relative_to": __file__} from the root of my repo, which would always point to the folder containing the repo, like /tmp when pip copies the package to somewhere for building.

@radugrosu, you wrote

The contents of setup.py are: [...] use_scm_version={"root": "..", "relative_to": __file__}

Which of the three setup.py were you referring to? Not the one in the root, I guess, because that would be wrong?

j08lue avatar Mar 05 '20 18:03 j08lue

@j08lue I'm seeing this with a much simpler structure:

<root>
├── .git
├── python
│   ├── name
│   │   ├── __init__.py
│   │   └── ...
│   └── setup.py

and when I do pip install . from the python directory, I get (with the traceback elided):

LookupError: setuptools-scm was unable to detect version for 'C:\\Users\\amerry\\AppData\\Local\\Temp'.

It appears that pip has copied the contents of the python dir to C:\Users\amerry\AppData\Local\Temp\tmpttcis7t9, which then means the .git directory is no longer located one up from setup.py.

amerry avatar May 21 '20 10:05 amerry

As pip keeps doing that, until I resolved with the pip developers how to do it reliably, i suggest to do editable installs

RonnyPfannschmidt avatar May 21 '20 11:05 RonnyPfannschmidt

FWIW, I found the discussion on https://github.com/pypa/pip/issues/7549 very useful - pip 20.1b1 solved my problem but they have since reverted the fix. I see this issue is referenced from the pip issue, but just bringing it back here :)

loodvn avatar Jul 07 '20 16:07 loodvn

thanks for the crosslink

RonnyPfannschmidt avatar Jul 08 '20 08:07 RonnyPfannschmidt

Hello, I have the exact same Pb

.
├── .git
├── api
│   ├── mf_hub_api
│   │   └── __init__.py
│   └── setup.py
├── pkg
│   ├── mf_hub
│   │   └── __init__.py
│   └── setup.py
└── README.rst

From both ./api and pkg python package pip install -e . work well but pip install . give me the traceback:

mf_hub/pkg$ pip install .
Processing .../mf_hub/pkg
...
LookupError: setuptools-scm was unable to detect version for '/tmp'.
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

My config.py::

mf_hub$ cat pkg/setup.py
from setuptools import find_packages
from setuptools import setup

requirements = """
pip
setuptools
wheel
setuptools_scm
"""

setup(
    name="mf_hub",
    setup_requires=["setuptools_scm"],
    use_scm_version={
        "write_to": "../version.txt",
        "root": "..",
        # "relative_to": __file__,
    },
    packages=find_packages(),
    test_suite="tests",
    install_requires=requirements,
    include_package_data=True,
    zip_safe=False,
)
mf_hub$

What could be a temporary workaround ?

LuisBL avatar Feb 11 '21 22:02 LuisBL

What could be a temporary workaround ?

Run

SETUPTOOLS_SCM_PRETEND_VERSION="$(python3 setup.py --version)" pip install .

This is the essence of workaround used in https://github.com/deltachat/deltachat-core-rust/blob/8ab3415c5803c7826245d3eca085b873ece38895/python/tests/package_wheels.py

link2xt avatar May 22 '21 23:05 link2xt

Did something that was fixed already break again for this?

I have a debian buster vagrant machine that throws the "unable to detect version" now and it used to always work.

tox  # works
fakeroot -u tox  # fails with "unable to detect version"

A debian bullseye vagrant machine with a very similar setup works.

https://github.com/borgbackup/borg/pull/7224 this is the code I used (see Vagrantfile).

BTW: on misc. ubuntu dists this is broken since a longer while.

ThomasWaldmann avatar Dec 24 '22 15:12 ThomasWaldmann

@ThomasWaldmann most likely a different issue, let's open a new one with more details

RonnyPfannschmidt avatar Dec 24 '22 16:12 RonnyPfannschmidt

Did something that was fixed already break again for this?

I have a debian buster vagrant machine that throws the "unable to detect version" now and it used to always work.

tox  # works
fakeroot -u tox  # fails with "unable to detect version"

A debian bullseye vagrant machine with a very similar setup works.

borgbackup/borg#7224 this is the code I used (see Vagrantfile).

BTW: on misc. ubuntu dists this is broken since a longer while.

tox 4.0 was released recently, and you probably want to add a [testenv:.pkg] section with passenv, because packages are now always built in a separate environment.

link2xt avatar Dec 24 '22 17:12 link2xt

Tox 4 was already resolved a while back for borgbackup

This time it was the git uid difference protection git coming in via vagrant vm updates

RonnyPfannschmidt avatar Dec 24 '22 17:12 RonnyPfannschmidt