Open jbohren opened 8 years ago
I wrote a tiny module called fastentrypoints
that monkey patches the mechanism behind entry_points
to generate scripts that don't import pkg_resources.
Unless I'm misunderstanding something, the fast entry points script will only improve things for the initial bootstrap from script into module— we also use pkg_resources here for handling plugins, so to really get the benefit, we'd need to do a couple things:
catkin -h
, in order to list available verbs.build_type
values other than catkin
or cmake
.Alternatively, we could do the caching / catkinrc
option proposed above, which is probably actually a better fit for handling completion. The trick would be avoiding needing to ever have the user manually refresh the file, which I think could be achieved using rules similar to the above:
@mikepurvis that all sounds right to me. Spinning off a daemon each time to update the file sounds scary, but I've done it the past with bloom (to check the version and report when you're out of date) and other tools use something like this to accelerate certain tasks. For example, bazel does this, but they actually leave theirs running for a long time (they call it a "long-lived server process"):
https://bazel.build/versions/master/docs/bazel-user-manual.html#client/server
So I think it's a good idea, with precedent.
just to mention for people who are still interested in this topic: we use the reentry package for this purpose - it's not yet perfect but it's a start.
The trick would be avoiding needing to ever have the user manually refresh the file
reentry does this via a post-install hook in the setup.py
(but it's not ideal: e.g. it doesn't work for installing wheels and it won't remove things from the cache when you uninstall).
pkg_resources is now deprecated. importlib.metadata is available for loading entrypoints in all supported (3.8+) versions of python
On my 2.9Ghz i7 with an EVO850 SSD running Ubuntu 12.04:
This means that using calls to the catkin script in tab-completion is a very laggy experience, and explains why there's a ubiquitous >200ms latency when running
catkin
commands. I think as it stands, catkin_tools is over-using theentry_points
interface. For example it's not necessary for the maincatkin
command, nor is it really necessary for the built-in verbs.I think the tool could be much more responsive if we used an alternative to
entry_points
for the verbs and build types. For example, mercurial uses a simple interface in.hgrc
to specify plugins explicitly, and I think we would be better off using a system like that.Currently
catkin
creates~/.config/catkin
andcatkinrc
could contain something like:Loading and reading a YAML file or INI is under 50ms:
Related: #295, #209