8000 RuntimeError: Broken installation: can't determine base dir · Issue #653 · python/mypy · GitHub
[go: up one dir, main page]
Skip to content

RuntimeError: Broken installation: can't determine base dir #653

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.

Sign up for GitHub

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

Jump to bottom
Closed
alunduil opened this issue May 1, 2015 · 20 comments
Closed

RuntimeError: Broken installation: can't determine base dir #653

alunduil opened this issue May 1, 2015 · 20 comments
Labels
feature

Comments

@alunduil
Copy link
Contributor
alunduil commented May 1, 2015

When installing via portage (I'm working on packaging mypy for portage), I get the following when trying to run mypy:

Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.3/mypy", line 169, in <module>
    main()
  File "/usr/lib/python-exec/python3.3/mypy", line 34, in main
    type_check_only(path, module, bin_dir, options)
  File "/usr/lib/python-exec/python3.3/mypy", line 78, in type_check_only
    python_path=options.python_path)
  File "/usr/lib64/python3.3/site-packages/mypy/build.py", line 122, in build
    data_dir = default_data_dir(bin_dir)
  File "/usr/lib64/python3.3/site-packages/mypy/build.py", line 191, in default_data_dir
    raise RuntimeError("Broken installation: can't determine base dir")
RuntimeError: Broken installation: can't determine base dir

I'm not sure what directory it's starting with but I can tell it's not finding what it's looking for. Any guidance would be appreciated.
@JukkaL
Copy link
Collaborator
JukkaL commented May 3, 2015

Can you give me the directories where different files from mypy live in your setup? Currently mypy is fairly rigid about where different files should live, but I'm happy to update this to support new configurations.

In particular, mypy needs to find the stub files.

@JukkaL JukkaL added the feature label May 3, 2015
@alunduil
Copy link
Contributor Author
alunduil commented May 6, 2015

Hey @JukkaL ,

Looks like those are in /usr/lib64. Here's a paste of every file installed:

https://bpaste.net/show/52a8a881523e

@JukkaL
Copy link
Collaborator
JukkaL commented May 12, 2015

Thanks for the info! I'll look into this, hopefully later this week. It should be pretty easy to fix.

@alunduil
Copy link
Contributor Author

@JukkaL Thanks! Let me know if you need anything else.

@alunduil
Copy link
Contributor Author
alunduil commented Jun 7, 2015

Looks like another Gentoo user found a solution in this bug: https://bugs.gentoo.org/show_bug.cgi?id=551272

I'm going to apply the patch to our ebuild and can submit it as a pull request if it's acceptable. Otherwise, let me know what a better solution would be.

@JukkaL
Copy link
Collaborator
JukkaL commented Jul 17, 2015

Apologies for not making progress on this. The fix in the linked issue doesn't work on Python 3.2, which we still support.

BTW, the paste link above apparently has expired.

@alunduil
Copy link
Contributor Author

@JukkaL, Thanks for looking into this again. Here's a new paste link and let me know if I can provide anything else.

https://bpaste.net/show/31ff1a7d0968

@icoxfog417
Copy link
Contributor

I'm facing this error too. It may be caused by below commit.

2c009ca

The change from scripts to mypy is not needed. Because mypy script exists under the Scripts folder in Windows (below is the point of change).

2c009ca#diff-564bf8da9227d198a635daea8a663e2bR173

mypy works fine when I reverted this change.

@JukkaL
Copy link
Collaborator
JukkaL commented Oct 17, 2015

@icoxfog417: Can you give me more details about your configuration (OS, Python version, are you using virtualenv, where are Python and mypy installed, which package did you use for Python)?

@icoxfog417
Copy link
Contributor

@JukkaL I'm sorry fot the lack of information.

  • OS: Windows 8.1

  • Python version: 3.5 and using Conda

  • The location that mypy command installed: (virtual environment root)/Scripts/mypy

  • mypy version: latest (from Github master branch (08dfca3))

    I tried it by virtualenv/Python 3.4, but the result was same.

And also, Windows doesn't have python3. So mypy script fails when using bash program (like msys2, cygwin).

#!/usr/bin/env python3
"""Mypy type checker command line tool."""

from mypy.main import main

main(__file__)

@icoxfog417 icoxfog417 mentioned this issue Nov 2, 2015
Merged
@alunduil
Copy link
Contributor Author

I'm still seeing this issue on Gentoo now that the aforementioned patch no longer applies to master. I can provide more information but I imagine it's the same as before. The current stack trace (slightly different):

% mypy --use-python-path -m MODULE
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.4/mypy", line 6, in <module>
    main(__file__)
  File "/usr/lib64/python3.4/site-packages/mypy/main.py", line 46, in main
    git.verify_git_integrity_or_abort(build.default_data_dir(bin_dir))
  File "/usr/lib64/python3.4/site-packages/mypy/build.py", line 224, in default_data_dir
    raise RuntimeError("Broken installation: can't determine base dir")
RuntimeError: Broken installation: can't determine base dir

@JukkaL
Copy link
Collaborator
JukkaL commented Dec 1, 2015

@alunduil Hmm.. some more information would be useful. Can you tell where the stub files are? For example, run this command and give me the output:

$ find /usr -name builtins.pyi

@icoxfog417 Sorry, I dropped the ball on your issue. I'll try to find time to do some testing on Windows later this week or the next week. If possible, it would be helpful if you can tell me where the builtins.pyi file lives in your installation.

@alunduil
Copy link
< 8000 span data-view-component="true" class="Label ml-1">Contributor Author
alunduil commented Dec 1, 2015

@JukkaL

Here's the results of that find command:

alunduil@elijah ~ % find /usr -name builtins.pyi
/usr/lib64/mypy/typeshed/builtins/3/builtins.pyi
/usr/lib64/mypy/typeshed/builtins/2.7/builtins.pyi

Let me know if any other information will help. I'm sure I didn't provide everything you need to troubleshoot the issue well.

@icoxfog417
Copy link
Contributor

My environment is as below. mypy works with some fixes.

  • Windows 7/32bit (Windows8.1 also)
  • Python 3.5
  • mypy version: latest (pip install git+https://github.com/JukkaL/mypy.git)
  • running on Git Shell (msys2)

There are some points.

  • I use latest mypy (master branch) because mypy on PyPI doesn't support Python 3.5 (PyPI version causes ImportError: cannot import name 'Undefined' due to the removing of Undefined type (please refer Remove Undefined #639)).
  • I have to modify mypy script file's header from #!/usr/bin/env python3 to #!/usr/bin/env python because that Windows doesn't have python3 command (If you use command prompt, it doesn't matter).

And the builtins.pyi is located in (my virtualenv folder)\Lib\mypy\typeshed\builtins\3.

Then mypy works.

$ mypy exmaple.py
exmaple.py:5: error: Argument 1 to "sum" has incompatible type "float"; expected "int"

example.py is like below.

def sum(x: int, y:int) -> int:
    return x + y

if __name__ == "__main__":
    print(sum(0.1, 2))  # causes type check error

@allthedata allthedata mentioned this issue Feb 20, 2016
Closed
@alunduil
Copy link
Contributor Author
alunduil commented Apr 3, 2016

@JukkaL, is there an easy fix for this that I can submit a pull request for? Why are paths hard coded rather than determined relative to a module or searched for in the lib search path?

@gvanrossum
Copy link
Member

The (somewhat) hard-coded paths are because installers put "data" files (in mypy's case that's the stub files) in different locations depending on platform and installer policies, and these locations aren't directly relative to where the code (the mypy package) is installed.

I guess if we could arrange to always install the stubs inside the "mypy" module that would make finding them easier (using pkgutil.get_data()), but this would require substantial changes to mypy's search for stub files. The current approach to finding stub files requires them to be in the filesystem, and that's why they are treated as "data".

@alunduil
Copy link
Contributor Author
alunduil commented Apr 4, 2016

That makes sense. Would you suggest adding the appropriate path for this issue or to look into revamping the stub file search code? I'm guessing the former since it's a simpler patch but that latter seems more robust.

@gvanrossum
Copy link
Member
gvanrossum commented Apr 4, 2016 via email

@alunduil
Copy link
Contributor Author
alunduil commented Apr 5, 2016

Found the culprit. It appears that following the symlinks that the mypy script is behind leads to /usr/lib/python-exec/python-exec? (where ? is the version, 2 or 3). This is due to Gentoo's use of dev-python/python-exec to handle multiple python installations and dynamic changes to the default implementation.

This base directory wasn't accounted for in the verify function in the git module. I'm testing a patch now and will submit a pull request if it's successful.

@gvanrossum
Copy link
Member
gvanrossum commented Apr 5, 2016 via email

alunduil pushed a commit to alunduil/mypy that referenced this issue Apr 5, 2016
add Gentoo path to default_data_dir
ff19445 
Gentoo uses a wrapper around pythons to handle their dynamic default
python selection on a system with many versions of python installed
simultaneously.  Due to this mypy's script is a symlink to a file in
/usr/lib/python-exec/python3.5.  This means that the search path needs
to check if python-exec is being used and return the appropriate path
(usually '/usr/lib').  This patch works successfully on my Gentoo system.

Fixes python#653.
@alunduil alunduil mentioned this issue Apr 5, 2016
Merged
gvanrossum pushed a commit that referenced this issue Apr 5, 2016
@gvanrossum
add Gentoo path to default_data_dir
bbd7007 
Gentoo uses a wrapper around pythons to handle their dynamic default

python selection on a system with many versions of python installed

simultaneously.  Due to this mypy's script is a symlink to a file in

/usr/lib/python-exec/python3.5.  This means that the search path needs

to check if python-exec is being used and return the appropriate path

(usually '/usr/lib').  This patch works successfully on my Gentoo system.



Fixes #653.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@alunduil @icoxfog417 @JukkaL @gvanrossum
0