Compare
$ time python -m pyflakes /dev/null
real 0m0.225s
user 0m0.103s
sys 0m0.008s
with $ time pyflakes /dev/null
real 0m2.468s
user 0m1.738s
sys 0m0.055s # python3 -m venv example
# source example/bin/activate
(example) # pip install pyflakes
Collecting pyflakes
Downloading pyflakes-1.5.0-py2.py3-none-any.whl (225kB)
100% || 225kB 892kB/s
Installing collected packages: pyflakes
Successfully installed pyflakes-1.5.0
(example) # time for i in {00..99}; do python -m pyflakes /dev/null; done
real 0m7.167s
user 0m6.407s
sys 0m0.750s
(example) # time for i in {00..99}; do pyflakes /dev/null; done
real 0m7.661s
user 0m6.894s
sys 0m0.753sFor me, it is not debugable. I wanted to propose and start a reference implementation for supporting --[no-]bool-opt, but I quickly gave up. There's some solutions on SO, but none of them are sufficient. The best solution makes --bool-opt mutually exclusive to --no-bool-opt which will cause a hard failure which is not okay for shell aliases.
I got stumped at:
"In particular, the magic happens in get_sneks. The call to pkg_resources.iter_entry_points('snek_types') iterates over all the entry points that were registered under the name "snek_types". So, external packages can define an entry point called "snek_types" in their setup.py, and snek will dynamically load it at runtime."
Wait. What entry points were registered under the name "snek_types"? Where were they regeistered as such? I think I must be missing something, or maybe that registration was hidden somewhere among all the fancy snakes. Can someone help explain this in a clearer way?
entry_points={
'snek_types': [
'cute = cute_snek:cute_snek',
],
}
The main snek codebase has: for entry_point in pkg_resources.iter_entry_points('snek_types'):
sneks[entry_point.name] = entry_point.load()
pkg_resources.iter_entry_points() iterates through all the snek_types an end user has installed on their system. When the end user does `pip install snek` they will only have the built-in sneks, when they also do `pip install cute-snek` the will have the "cute" snek installed, allowing them to run `snek --type cute` to see it.I agree it's not super well organized, they should have printed the new setup.py before that bit.
I initially just skimmed over his log dump from the install, but I think the details are actually important there:
> writing entry points to cute_snek.egg-info\entry_points.txt
from setuptools import setup
setup(
name='snek',
entry_points={
'console_scripts': [
'snek = snek:main',
],
}
)
It's using the setuptools module, and passing a tuple to it - which is used to create executables for the individual scripts once installed.https://packaging.python.org/tutorials/distributing-packages...
Specifically, "entry_points" in the setup tuple is what sets the name of the created files and links them to your code. In the example, the executable 'snek' points to main() in snek.py.
Once your package is installed, pip or easy_install handles the magic of putting those files in place. There are boatloads of other options available (much like any packaging system), but this is a minimum viable example.
[1] - https://docs.openstack.org/stevedore/latest/index.html