Clone wiki

gorilla / PackageMaintainers

Requirements from Package Maintainers

There should be none. Period.

People shouldn't have to wait for the maintainer of their favorite package to support this tool, they should be able to create a new card for it in 2 minutes (and optionally send a patch to the catalog maintainers).

Optional Support

We could give maintainers the option to support the tool by adding a .gorilla file in their project's root folder. That file could contain a subset of a recipe, like this:


# These will be run in the cloned or unextracted directory, before symlinking
build_commands = [
    'make local',

# These will be symlinked into the tool's packages directory, which users will
# add to their $PYTHONPATH
packages = [

# These will be symlinked into the tool's bin directory, which users will add
# to their $PATH
scripts = [

If that file is present we can read those items from that file. That would fix the problem of changing symlink/build requirements -- if the requirements change the maintainer changes that file on their own and commits it with the rest of the code.

There's a lot of versions out there already tagged out there though, and it requires package maintainers to care about this tool, so it definitely doesn't solve all the problems.

Steve: I'm not sure how I feel about this. It reeks of Are there enough edge cases (say more than 10% of common packages) where something like this would be worth supporting?

Paul: I think it could be good. It's not quite because it's completely optional. We could run into issues if a package already has a recipe, but then decides to provide a .gorilla file as well. I guess the .gorilla file would win if there were any settings conflicts. Shouldn't be too hard to merge the two.