The ideal way to do this is to give setuptools
an Entry Point.
Instead of writing a script, you write a function in one of your modules.
For example, add this line to your setup
call in setup.py
:
entry_points = {
'console_scripts': ['mytool'=mypkg.myscript:myfunc'],
}
… and setuptools
will, at install time, automatically create a script named mytool
that imports mypkg.myscriptand calls its
myfunc, all in a way that's appropriate for whatever Python installation the user used to
pip installyour package, and put
mytoolonto the user's
PATH`.
This way, it takes care of all kinds of portability issues you never even thought of. What if the user is on Windows and their default Python is 2.7 but they used py -3 -m pip
to install it? They'll get a file named mytool.py
instead of mytool
, and it'll have a Windows py
-launcher-compatible shbang line, and it'll just work.
Occasionally, you can't reorganize things that way, and you have to manually write a script. In that case, just give setuptools
the path to the script, by adding this argument to your setup
call:
scripts=['bin/mytool']
setuptools
can't do all of its magic here, but it can still get the script installed into the user's PATH
.
Of course all of this depends on Python being set up properly. But however Python managed to put pip
and django-admin
on your PATH
, then it will put your script on the PATH
in the exact same way.