Open akrabat opened 3 years ago
As far as I understand:
entry_points
in their setup.py.scripts
, namely it symlinks them from the app's virtualenv to ~/.local/bin
scripts
instead of entry_points
, because they need to set PYTHONIOENCODING
: the switch to entry_points contributed by @cs01 in 2018 was later reverted in September 2019 https://github.com/dbcli/mssql-cli/pull/299Seems like it's a pipx issue, which should at least document the solution for people who want to use non-python scripts
that run python -m
and expect their module to be installed. Or maybe install a wrapper executable to .local/bin
, that activates the correct virtualenv and runs the original script afterwards.
Note that .py scripts
like https://github.com/aws/aws-cli/blob/c1c11afa6b4a76e3790b618ed746feeb25f70446/bin/aws#L1 on nix work auto-magically because something rewrites their shebang to point to the python executable from the app's virtualenv.
Oh, the workaround is to change the last line of ~/.local/bin/mssql-cli
to point to the virtualenv's python (on my system it's ~/.local/pipx/venvs/mssql-cli/Scripts/python -m mssqlcli.main "$@"
)
A merged PR implies that pipx can be used, but it doesn't work for me.