No console entry point for Windows

[johnthagen]

On Windows 10 x64 using Python 3.5.1:

>pip -V
pip 8.0.2
>pip install mypy-lang
>pip list
...
mypy-lang (0.3.1)
...
>mypy
'mypy' is not recognized as an internal or external command,
operable program or batch file.

I think what would be helpful for Windows users would be a console_scripts entry_point:

setuptools.setup(
    ...
    entry_points={
            'console_scripts': [
                'mypy = (INSERT MAIN MODULE):main',
            ],

This will work on Linux and Windows.

[gvanrossum]

Is there a way to do this without depending on setuptools? In my experience setuptools adds as many problems as it solves (different one though :-).

[refi64]

Why not add a mypy.bat that just calls python -m mypy.__main__?

[johnthagen]

@gvanrossum I haven't run into issues using setuptools personally, so would have to defer to you on that. I'm curious to learn what some of these issues are, could you elaborate?

[gvanrossum]

I can't elaborate on issues with setuptools, I just remember having been really frustrated at various points in the past by things that broke due to some setuptools cleverness. Isn't there some pip goodness that replaces setuptools entry points?

[johnthagen]

@gvanrossum Not one that I am aware of. All of the places I've found have stated that setuptools is the solution.

• Armin Ronacher's Click Documentation
• Chris Warrick's Blog
• StackOverflow Question 1
• StackOverflow Question 2
• Python Packaging Authority Docs

setuptools Documentation explains how the Windows .exe's are created

[gvanrossum]

So, why can't we install scripts/mypy in the right place on Windows? That's what it's meant for.

[johnthagen]

I may be mistaken, but I think a fundamental issue on Windows is that there is no concept of a shebang line, so you need an executable mypy.exe rather than simply a script in order to let the user do:

$ mypy

Even if scripts/mypy is in the PATH, it can't be executed directly on Windows.

[refi64]

Again, simple fix: use a batch file!

[gvanrossum]

I would like to have this fixed but I have no access to Windows. Can someone just contribute a .bat file as a PR, including the setup.py mods to install it?

[ghost]

Because I've decided to make life hard for myself: I don't think a somewhat simple bat file is enough, unless its generated on install (which then becomes a console entry point pretty much), or has extra logic added (which I don't think anyone wants to do, but would be a solution)

I have python 3.5 installed in Program Files (as is suggested by the installer), and I have pip installing to the --user location C:\Users\Username\AppData\Roaming\Python\Python35\<subfolders>

C:\somepath>where python
C:\Program Files\Python35\python.exe

C:\somepath>where mypy
C:\Users\Username\AppData\Roaming\Python\Python35\Scripts\mypy
C:\Users\Username\AppData\Roaming\Python\Python35\Scripts\mypy.bat

C:\somepath>mypy
'"C:\Users\Username\AppData\Roaming\Python\Python35\Scripts\..\python"' is not recognized as an internal or external command, operable program or batch file.

(since the bat file tries to access ../python from mypy.bat's location)

of course py -3 -m mypy still works fine, but I figured it would be worth mentioning!

[refi64]

@Socialery Hmm... Maybe setup.py should somehow process the .bat file and hardcode the correct Python location...

Either that, or Windows can burn in a violent fire. I kind of like that option better.

[gvanrossum]

I don't like Windows either, but something like 70% of Python users are actually on Windows... So I think we should come up with something. I like the idea of processing the .bat file on install.

[johnthagen]

Just want to throw out that setuptools really does have support for this (console entry points), and it works great in my experience. Don't think mypy needs to reinvent this.

Is there really a solid reason not to use the solution that has been used many times over by other Python packages?

[gvanrossum]

Have you seen #1875? That was an attempt at adding a console entry point, but the author never got it to work. Feel free to submit a PR that works!

[johnthagen]

Edit: Not sure if I'll have time to work on this, so opening it up for others to work on.

[gvanrossum]

Maybe it's time to reconsider this? At least we're now using setuptools!

[alexandrul]

@johnthagen could you test this proof of concept, please? https://github.com/alexandrul-ci/mypy/

[johnthagen]

@alexandrul

I tried this on a Windows 10 x64 host running Python 3.6.0.

> py -3.6 -m venv venv
> Scripts\activate.bat

# Checked out https://github.com/alexandrul-ci/mypy/

> pip install "C:\Users\User\PycharmProjects\mypy"
Processing c:\users\user\pycharmprojects\mypy
Collecting typed-ast>=0.6.3 (from mypy==0.480.dev0)
  Using cached typed_ast-0.6.3-cp36-cp36m-win_amd64.whl
Installing collected packages: typed-ast, mypy
  Running setup.py install for mypy ... done
Successfully installed mypy-0.480.dev0 typed-ast-0.6.3
> mypy -V
mypy 0.480-dev
> mypy --help
usage: mypy [-h] [-v] [-V] [--python-version x.y] [--platform PLATFORM] [-2]
            [--ignore-missing-imports]

Appears to be working.

[alexandrul]

@johnthagen thank you

On my PC I have tested it with an altered sample from mypy, I have the same issues reported with my version as with the original 0.470.

[emmatyping]

I believe this can be closed as we are using the newer entry point method.

[ghost]

just checked for my edge-case of a python install, seems to work great now (well, the entry point does at least!)