Warn if package contains console_scripts without listing entry_points

[stuarteberg]

Update: This is known and unavoidable behavior, as explained in the thread below. So instead of a fix, a warning would be nice.

---

I'm confused about how to package console_scripts entrypoints in a way that will work on Windows. This is related to #3731, but I think it's not exactly the same issue.

Here is a minimal example of a package and conda recipe that defines an entry point via console_scripts. The entry point is tested in the recipe, which works fine on linux, but fails on Windows:

(%PREFIX%) %SRC_DIR%>call "%SRC_DIR%\run_test.bat"

(%PREFIX%) %SRC_DIR%>foo_main
Fatal error in launcher: Unable to create process using '"c:\programdata\miniconda3\conda-bld\foo_1590987579272\_h_env\python.exe"  "C:\ProgramData\Miniconda3\conda-bld\foo_1590987579272\_test_env\Scripts\foo_main.exe" ': The system cannot find the file specified.

As you can see, the issue is that pip creates an entry point with a hard-coded reference to ...\_h_env\python.exe, and conda-build doesn't patch that prefix. In fact, conda-build's own test suite expects and enforces this non-replacement behavior. That seems to be in conflict with what the docs suggest, but maybe I'm confused:

However, pip creates executables for Python entry points that do use embedded paths on Windows. Conda-build thus detects prefixes in all files and records them by default.

So, what is the proper way to package console_scripts on WIndows?

Edit: OK, While writing up this issue, I noticed that this problem occurs with python -m pip install ., but not with python setup.py install. I suppose that's a workaround. But it would be nice to know what the intended solution is.

Edit: I now see that conda-build's entry_points feature also serves as a workaround. (I tested it.) Are recipe authors required to list all console_scripts as conda-build entry_points? If so, perhaps a warning should be issued for any console_scripts that the recipe author has neglected to explicitly list in meta.yaml.

Actual Behavior

conda-build does not replace the prefix in pip-generated console_scripts, which means those scripts don't work.

Expected Behavior

I thought conda-build would treat those files as binary files, and therefore replace the prefix so it gets updated at install time.

Steps to Reproduce

Build the recipe contained in this repo on a Windows machine. The test will fail with the error shown above.

Output of conda info

(base) c:\Users\stuarteberg\foo>conda info

     active environment : base
    active env location : C:\ProgramData\Miniconda3
            shell level : 1
       user config file : C:\Users\stuarteberg\.condarc
 populated config files : C:\Users\stuarteberg\.condarc
          conda version : 4.8.3
    conda-build version : 3.18.11
         python version : 3.7.6.final.0
       virtual packages :
       base environment : C:\ProgramData\Miniconda3  (writable)
           channel URLs : https://conda.anaconda.org/conda-forge/win-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/win-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/win-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/msys2/win-64
                          https://repo.anaconda.com/pkgs/msys2/noarch
          package cache : C:\ProgramData\Miniconda3\pkgs
                          C:\Users\stuarteberg\.conda\pkgs
                          C:\Users\stuarteberg\AppData\Local\conda\conda\pkgs
       envs directories : C:\ProgramData\Miniconda3\envs
                          C:\Users\stuarteberg\.conda\envs
                          C:\Users\stuarteberg\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/4.8.3 requests/2.22.0 CPython/3.7.6 Windows/10 Windows/10.0.17763
          administrator : True
             netrc file : None
           offline mode : False

[mingwandroid]

Conda is technically incapabale of doing binary prefix replacement on Windows because we do not have the 256 byte path prefix space in which to work. This is not something conda/conda-build have ever done and this test makes sure of that for this specific case.

You are required to tell conda-build about entry points in all scenarios on Windows.

[mingwandroid]

Regarding the documentation, it's confusing I agree, but recording != rewriting.

[stuarteberg]

Thanks for the explanation, Ray! I am not a regular Windows user, so I wasn't aware of this issue. I think a warning or error from conda-build would give the clueless uninitiated (such as myself) some idea of what's going on. I will change the title of this issue. If I get a chance, I will work on a PR.

[ndevenish]

Count me in as another person who spent a day or so debugging because of this (saved by finding this thread; It didn't help that on my CI the message about missing the host-environment python path was suppressed, so a lot of that was tracing the problem to conda-build).

I also completely unambiguously interpreted this paragraph to mean that it should work and not be an issue. Only in retrospect knowing the issue did that and "Making packages relocatable" interpreted with rather excessive word-lawyering somewhat make the issue understandable.

FWIW the docs imply that they should be automatically registered into info/has_prefix even if it isn't found; this at least for me doesn't appear to be the case. And "The build prefix must therefore be long enough to accommodate any reasonable installation prefix.". MacOS and Linux are mentioned as special cases at several points; nowhere does it make clear that Windows doesn't do this at all.

I'll try and have a think about how the wording could be improved; since it specifically mentions python/pip as a known exception, maybe just a sentence saying that they must be registered in one or the other documentation locations would be enough.

[bnavigator]

conda-forge/numpy-feedstock#276 also falls into this category.
Open question about it in #4291

This needs to be documented better.

[github-actions]

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

1. Verify that you can still reproduce the issue at hand
2. Comment that the issue is still reproducible and include:
   - What OS and version you reproduced the issue on
   - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!