clarify requirements

[SSE4]

this topic actually has multiple questions to clarify

• [ ] can plug-in depend on other python libraries (e.g. lief, requests)? if so, how to specify them (e.g. requirements.txt)?
• [ ] ~~can plug-in have build_requirements? (e.g. if it depend on external tool like git, ninja or whatever)~~
• [ ] ~~can plug-in have system_requirements? (as above, to install system tools, like git)~~
• [ ] ~~can plug-in have python_requirements? (to share code between plug-ins)~~
• [ ] ~~can plug-in have requirements?~~

UPDATE: it turns out, hooks cannot use any of conan dependencies, like requirements, system_requirements, python_requirements or build_requerements, as they invoke conan methods, which has to be hooked, and it goes into infinite vicious circle. moreover, hooks should be very careful choosing which conan API to use, in order to avoid such infinite recursion.

/cc @solvingj @Croydon @uilianries @lasote @memsharded @danimtb @jgsogo

[solvingj]

It seems to depend on which of the paths are taken to manage plugins. If plugin distribution is supported using both PIP and Conan packages, then all of these seem possible.

PIP packages are nice because it allows the author to show the actual "python-level-dependencies" in the setup.py/requirements.txt , which is the normal python way. It also allows the project to be structured like a normal python package (unit tests, etc).

Conan packages are nice for other reasons. They can be defined in Conan profiles. They can leverage a all the "executable" dependencies available as build_requires. Users are not required to setup and maintain their own PIP repository in addition to their Conan repository if they want to deploy plugins in their internal environments. In theory, they can even use python_requires to share code with each other.

I see advantages to both mechanisms, so I would vote for both to be supported. The only mechanism I would never see using is conan config install, because it doesn't support versioning.

[jgsogo]

I think that this plugins/hooks are something restricted to python tools, they cannot depend on Conan machinery as it may not be available at the moment the function is about to run. How can a pre_download depend on something (python/build/system_requirement) that has to be downloaded?

[SSE4]

@jgsogo @danimtb do we have a conclusion yet on how plug-ins/hooks should specify their requirements?

[danimtb]

Probably organize them in folders with its own readmes and requirements.txt?

[uilianries]

and licenses

[jgsogo]

There are two levels to talk about this:

• how to organize them in the cache
• how to organize them in this repo

I'm focusing in the second point:

Requirements

Hooks are not being installed using pip so they can only rely on what the user already has installed in their working environment. I think that all they can do is having a check at load time, and the hook_manager may handle the exception:

from conans.error import ConanException

try:
    from coollibrary import coolfeature
except ImportError:
    raise ConanException("coolfeature is required to run 'MY COOL HOOK', install it using `pip install ....`")

I'm not sure if the hook_manager is prepared to handle and exception on loading time (and how this exception will be written).

Licenses

All the hooks in the repo should use the same license, shouldn't they?

README

Yep, we have to think about how to organize the documentation of this repo, some hooks may need a longer explanation.

[uilianries]

Hooks are not being installed using pip so they can only rely on what the user already has installed in their working environment.

I agree. It sounds more like plugins

All the hooks in the repo should use the same license, shouldn't they?

since hooks can be distributed and shared, I think they could have multiple licenses. I've used __license__ attribute instead to add a new file, but for custom licenses it won't work.

[danimtb]

I came across an issue installing LIEF dependency from binray_linter hook. I am running Python 3.7 in a Windows machine and it seems there is no support of py3.7 in Lief.

Thinking about the requirements maybe we could think about a way to manage this kind os thing providing more information in the hook metadata and implement some logic in the HookManager inside de conan client

[SSE4]

@danimtb could you paste here what's the current conan's output or error message when you try to install hook which requires missing dependency like LIEF?

[danimtb]

@SSE4 is not an error in "installation" as Conan does not check anything when you place hooks under the hooks folder. The error comes when yo execute Conan and it tries to load the hook file:

$ conan create . danimtb/testing
ERROR: Error loading hook 'C:\Users\danimtb\.conan\hooks\conanio\hooks\binary-linter.py': Unable to load Hook in C:\Users\danimtb\.conan\hooks\conanio\hooks\binary-linter.py
  File "C:\Users\danimtb\.conan\hooks\conanio\hooks\binary-linter.py", line 6, in <module>
    import lief
ModuleNotFoundError: No module named 'lief'

I think the error would be quite familiar to people even with little experience in Python and in any case we could always wrap the import around as suggested by Javi https://github.com/conan-io/hooks/issues/7#issuecomment-458505345 (or implement the functionality in Conan)