You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What inspired #224 and #223 (to a degree) was me installing Peru as a dev-dependency in a project where I need to get data from internal artifact storage before running tests. Turns out that the container in which we're running tests does not have git installed! This makes sense, because the container only has the bare minimum stuff necessary to retrieve dependencies and run tests. Another container has already handled the initial git clone.
Poking around a little, the git plugin uses git, obviously:
I think both of these could stand to benefit from another module that abstracts away some git command building, minimally starting with a "is git available?" check. Having a user-friendly error that git isn't installed would have saved me (and the person who actually started using Peru at my behest) some time. This probably applies to the other plugins, although I didn't look at them.
The abstraction probably shouldn't grow to the size of GitPython without considering migrating to that tool.
The text was updated successfully, but these errors were encountered:
The main reason we haven't done something like this already is that peru tries pretty hard to keep itself to a single external invocation of the git binary in the happy path. So like if you run peru sync it does a tun a work and runs a bunch of commands. But if you run peru sync again, it does very little. Currently only a single command to check the status of the tree. This is an imporant part of the "put peru sync in your Makefile or at the top of your Bash script and then forget about it" strategy.
So if checking for git meant shelling out to git --version or similar, that wouldn't be ideal. Is there another way of checking that you had in mind?
That hidden abstraction layer is wonderful and one of the things I really like about the tool.
I think this check could be achieved through the use of which , which the shutil built-in has in shutil.which():
importshutildefis_utility_available(cmd):
returnshutil.which(cmd) isnotNonedefrequire_git():
ifnotis_utility_available("git"):
raiseMissingUtilityException("git is unavailable. Please install git and re-run your command.")
Drop require_git() early into any path that will need git and the user who forgot git will love the helpful error message instead of a FileNotFoundError or whatever is thrown with a long traceback.
What inspired #224 and #223 (to a degree) was me installing Peru as a dev-dependency in a project where I need to get data from internal artifact storage before running tests. Turns out that the container in which we're running tests does not have git installed! This makes sense, because the container only has the bare minimum stuff necessary to retrieve dependencies and run tests. Another container has already handled the initial git clone.
Poking around a little, the git plugin uses git, obviously:
peru/peru/resources/plugins/git/git_plugin.py
Lines 13 to 17 in f16cd2d
and the cache module uses it for the backend:
peru/peru/cache.py
Lines 54 to 58 in f16cd2d
I think both of these could stand to benefit from another module that abstracts away some git command building, minimally starting with a "is git available?" check. Having a user-friendly error that
git
isn't installed would have saved me (and the person who actually started using Peru at my behest) some time. This probably applies to the other plugins, although I didn't look at them.The abstraction probably shouldn't grow to the size of GitPython without considering migrating to that tool.
The text was updated successfully, but these errors were encountered: