Managing optional dependencies when publishing to Hex


I can’t seem to find much on how to properly handle optional dependencies for libraries intended to be used by others (e.g. published on Hex).

I’ve published ScrapyCloudEx to Hex. It interacts with an API, and I want to provide users with a default way to do so while also enabling them to customize the “middleware” (e.g. using a different or custom http client).

For example, the library provides a default http client that uses :hackney. If a user is going to use a different http client, I don’t want to force them to install :hackney, nor do I want them to have to deal with (e.g.) warnings about Hackney being absent. I’ve tried various approaches, and none fully addressed my issues.

Trying to use just optional: true (docs) for Hackney and Jason in mix.exs but ran into problems.

I then (in addition) tried to conditionally compile the default http client only if hackney is present (commit) which @ericmj suggested here, but once published to Hex when I require my package again I systematically get the error about Hackney being absent even if it’s included as a dependency (along with scrapy_cloud_ex) in my test project.

I then reverted that commit/approach, but now users will get warnings during compilation about (e.g.) the Hackney module not being available because since it’s not listed as a dependency of ScrapyCloudEx it doesn’t necessarily get compiled before it.

What am I doing wrong? What is the recommended approach for this? Is there another project doing something similar that I can refer to?

Can you show the errors you got when the dependencies were declared as optional and please point to the commit in your repository when they were optional so that we can try and reproduce.

The problems I had were resolved when recompiling after deleting _build and deps as you suggested here. As far as I can tell, there’s no issue with Hex and the issue lies with Mix so I’ve documented the relevant reproduction in that thread.

1 Like