Support installs without EASY-INSTALL-ENTRY-SCRIPT

[nikitalita]

easy_install has been deprecated: https://setuptools.pypa.io/en/latest/deprecated/easy_install.html

Sometime this month, the default behavior of pip changed (I can't find documentation on WHEN exactly it changed, or what version, I spend a couple hours banging my head against the wall to try and figure that out).

If a pyproject.toml is present in addition to setup.cfg, and if installing as editable, it will install using pyproject.toml. This means that it will no longer create the EASY-INSTALL-ENTRY-SCRIPT that gravitybee relies on for creating the standalone binary. On Windows, it will only create the exe without the entry script. This means gravitybee will fail to build the standalone binary when it can't find the script.

See this issue for more details: miurahr/aqtinstall#556

Given that easy_install is deprecated and support will be dropped entirely in the near future, there's a great chance that this script will just not be created at all in the future with pip installs.

So, that means that gravitybee will have to implement an alternative to just using that script; perhaps it could automatically generate one based on how setuptools does it now? It doesn't look too complicated and seems to be fairly standard for all packages installed.

[lorengordon]

Hello again @nikitalita! If the issue is a change in pip/setuptools, as a workaround, does it help to pin those versions in your build pipeline?

We haven't tried using pyproject.toml in any project, so haven't run into this yet ourselves. I don't think we're explicitly using easy_install anywhere that I can see. I don't think it occurred to us that the .py script installed by pip even had anything to do with easy_install? Interesting.

I don't actually see where we are using script_path. Are we just copying it into the directory structure so it is packaged up in the standalone binary? Maybe if it isn't present, we can just skip it?

If you have some ideas going already and are willing to work on a PR, I will be happy to review and get a release out for you.

[lorengordon]

Oh I see, the file gets copied and referenced by another name, and ends up as part of the pyinstaller command. So we should probably figure out how pyinstaller is supporting pyproject.toml...?

gravitybee/gravitybee/__init__.py

Lines 903 to 905 in 1bea96f

	commands += [
	self._temp_script
	]

[lorengordon]

Hmm, reading through the pyinstaller docs, and they all seem to reference either the .py script, or a spec file. But I rather expect it works fine with projects that use pyproject.toml since I didn't see any promising issues in their tracker. So now I'm wondering if there might be something odd about the build setup in https://github.com/miurahr/aqtinstall that caused the .py file to not be created? Or maybe it was created in an unexpected path??

[nikitalita]

Hmm, reading through the pyinstaller docs, and they all seem to reference either the .py script, or a spec file. But I rather expect it works fine with projects that use pyproject.toml since I didn't see any promising issues in their tracker. So now I'm wondering if there might be something odd about the build setup in https://github.com/miurahr/aqtinstall that caused the .py file to not be created? Or maybe it was created in an unexpected path??

no, it has nothing to do with AQT. I tested this locally with earlier versions of AQT, and they also failed to build. They built fine on github actions some months ago, and I made sure that I used the same version numbers of setuptools and pip in their respective release build logs.

I have no idea what happened, it may be a dep of setuptools and pip, but either way, this is apparently expected behavior going forward.

[lorengordon]

Let me come at it from another way, where are you seeing any evidence that the .py script is specific to easy_install and that it is supposed to be going away? From some initial research, it seems to me that it is still expected that it should be created. And pyinstaller still appears to require/expect this .py script also.

So my question was meant to focus more on, why isn't the .py script being created? Perhaps there is something about using setuptools and pyproject.toml and editable installs that is at the root of the problem.

[lorengordon]

Hello again @nikitalita, just following up here. Good and bad news... We recently had reason to update the build pipeline for the main project we needed gravitybee for in the first place, and we are able to reproduce the same problem you're seeing... On Windows, a project using setuptools with a pyproject.toml will not generate the same entrypoint .py script. We tested the workaround, removing the pyproject.toml, and confirmed that does indeed work, also.

However, we were able to refactor and use a simple entrypoint script and pyinstaller hook to build the standalone package without gravitybee at all. Since it turns out to be easy enough to use pyinstaller directly, our intent is to archive gravitybee. It will remain available, but there will be no further releases.

Below is the setup we're now using. You can get more details in the pr where we implemented the change.

pyinstaller command:

pyinstaller --noconfirm --clean --onefile \
    --name "$WAM_FILENAME" \
    --runtime-tmpdir . \
    --paths src \
    --additional-hooks-dir "$PYI_HOOK_DIR" \
    --distpath "$PYI_DIST_DIR" \
    --specpath "$PYI_SPEC_DIR" \
    --workpath "$PYI_WORK_DIR" \
    "$PYI_SCRIPT"

entrypoint script:

from watchmaker.cli import main

if __name__ == "__main__":
    main()

hook:

from PyInstaller.utils.hooks import (collect_data_files, collect_dynamic_libs,
                                     collect_submodules, copy_metadata)

datas = []
binaries = []
hiddenimports = [
    "boto3",
]
datas += copy_metadata("watchmaker", recursive=True)
datas += collect_data_files("watchmaker")
binaries += collect_dynamic_libs("watchmaker")
hiddenimports += collect_submodules("watchmaker")