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 itsmyfunc, all in a way that's appropriate for whatever Python installation the user used topip installyour package, and putmytoolonto the user'sPATH`.
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.