8000 Make typing and typed-ast external dependencies by gvanrossum · Pull Request #2452 · python/mypy · GitHub
[go: up one dir, main page]

Skip to content

Make typing and typed-ast external dependencies #2452

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

Merged
merged 9 commits into from
Jan 6, 2017
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add comments clarifying some things added here
  • Loading branch information
Guido van Rossum committed Jan 6, 2017
commit 08c86df09c406cdc96fd67c7687ad5ba67ffa389
4 changes: 4 additions & 0 deletions setup.cfg
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,10 @@ parallel = true
show_missing = true

[metadata]
# This seems to be used only by bdist_wheel.
# You need "pip3 install wheel".
# Then run "python3 setup.py bdist_wheel" to build a wheel file
# (and then upload that to PyPI).
requires-dist =
typed-ast >= 0.6.1; sys_platform != 'win32'
typing >= 3.5.2; python_version < "3.5"
7 changes: 7 additions & 0 deletions setup.py
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,9 @@
sys.stderr.write("ERROR: You need Python 3.2 or later to use mypy.\n")
exit(1)

# This requires setuptools when building; setuptools is not needed
# when installing from a wheel file (though it is still neeeded for
# alternative forms of installing, as suggested by README.md).
from setuptools import setup
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This causes $VERSION to be set as an environment variable, hence cobertura tests fail. I'm looking into how to fix this cleanly. Also, I don't quite understand why 3.6 tests passed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really? By what mechanism does $VERSION get set?

Copy link
Contributor
@ambv ambv Dec 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am talking nonsense. What happens is as follows:

  • the XML report template in test-data/unit/cmdline.test has $VERSION and $TIMESTAMP abstracted away because they will obviously be different too often
  • the code responsible for it is in mypy/test/testcmdline.py, line 101
  • however, with setuptools the test runner's mypy.__version__ is "0.4.7-dev-2c9250eb182708402c66f8197f62ebe0190a43d5-dirty" so it doesn't replace the "0.4.7-dev" string in the XML

I'm investigating now why this is the case.

Copy link
Contributor
@ambv ambv Dec 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test harness does python setup.py install which is different on setuptools from python setup.py develop (which is the equivalent of pip install -e .).

There's two ways forward to fix this:

  1. Since local developers are likely going to keep using pip install -e . or equivalent, we can simply change the command that says python setup.py install to say python setup.py develop. I don't like this because this makes the cmdline test less isolated (we never perform a complete installation).
  2. Alternatively, let's just add line 102 to mypy/test/testcmdline.py which performs another replace to $VERSION, but this time using mypy.version.base_version and not mypy.version.__version__. This makes it work for both cases and won't break when we implement Version doesn't include git commit hash when installed via "pip3 install ." #2547.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I think about as far as I got the previous time around. The big mystery is why 3.6-dev behaves differently. I noticed that there was something different in the way lxml is installed. See previous comments (search for lxml).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm for (2). I'm not sure what pip install -e . or python setup.py develop do (the help text is kind of minimal) so (1) is particularly unattractive for me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why setuptools would behave differently on 3.6, no idea. lxml 3.6.4 is a red herring, the difference is because there is a lxml 3.6.4 wheel pre-built for 3.5 on PyPI but none for 3.6. This went away BTW since there's just .tar.gz for lxml 3.7.0.

I can confirm both of my suggested fixes solve the failure.

from setuptools.command.build_py import build_py
from mypy.version import base_version
Expand Down Expand Up @@ -92,6 +95,10 @@ def run(self):
if os.name == 'nt':
scripts.append('scripts/mypy.bat')

# These requirements are used when installing by other means than bdist_wheel.
# E.g. "pip3 install ." or
# "pip3 install git+git://github.com/python/mypy.git"
# (as suggested by README.md).
install_requires = []
if sys.platform != 'win32':
install_requires.append('typed-ast >= 0.6.1')
Expand Down
0