Suggest to loosen the dependency on funcy

[Agnes-U]

Hi, your project detect-waste requires "funcy==1.15" in its dependency. After analyzing the source code, we found that some other versions of funcy can also be suitable without affecting your project, i.e., funcy 1.16, 1.17. Therefore, we suggest to loosen the dependency on funcy from "funcy==1.15" to "funcy>=1.15,<=1.17" to avoid any possible conflict for importing more packages or for downstream projects that may use detect-waste.

May I pull a request to loosen the dependency on funcy?

By the way, could you please tell us whether such dependency analysis may be potentially helpful for maintaining dependencies easier during your development?

---

For your reference, here are details in our analysis.

Your project detect-waste(commit id: 6113385) directly uses 3 APIs from package funcy.

funcy.seqs.lfilter, funcy.seqs.lremove, funcy.seqs.lmap

From which, 14 functions are then indirectly called, including 9 funcy's internal APIs and 5 outsider APIs, as follows (neglecting some repeated function occurrences).

[/wimlds-trojmiasto/detect-waste]
+--funcy.seqs.lfilter
|      +--funcy.compat.lfilter
|      |      +--itertools.ifilter
|      +--funcy.funcmakers.make_pred
|      |      +--funcy.funcmakers.make_func
|      |      |      +--funcy.strings.re_tester
|      |      |      |      +--re.compile
|      |      |      +--funcy.strings.re_finder
|      |      |      |      +--funcy.strings._prepare
|      |      |      |      |      +--re.compile
|      |      |      |      |      +--funcy.strings._make_getter
|      |      |      |      |      |      +--operator.methodcaller
|      |      |      +--operator.itemgetter
+--funcy.seqs.lremove
|      +--funcy.seqs.remove
|      |      +--funcy.funcmakers.make_pred
+--funcy.seqs.lmap
|      +--funcy.compat.lmap
|      |      +--itertools.imap
|      +--funcy.funcmakers.make_func

We scan funcy's versions among [1.16, 1.17] and 1.15, the changing functions (diffs being listed below) have none intersection with any function or API we mentioned above (either directly or indirectly called by this project).

diff: 1.15(original) 1.16
['funcy.colls.has_path', 'funcy.calc.CacheMemory.__setitem__', 'funcy.decorators.has_1pos_and_kwonly', 'funcy.calc.CacheMemory.expire', 'funcy.calc.memoize', 'funcy.calc.SkipMemoization', 'funcy.flow.throttle', 'funcy.calc.CacheMemory', 'funcy._inspect.get_spec', 'funcy.decorators.decorator', 'funcy.calc.CacheMemory.clear', 'funcy.flow._ensure_exceptable', 'funcy.flow.reraise', 'funcy.funcs.curry', 'funcy.decorators.has_single_arg', 'funcy.calc.CacheMemory.__init__', 'funcy.calc._memory_decorator', 'funcy.funcs.autocurry', 'funcy.calc.SkipMemory', 'funcy.calc.CacheMemory.__getitem__', 'funcy.calc.cache', 'funcy.flow._is_exception_type', 'funcy.funcs.rcurry']

diff: 1.15(original) 1.17
['funcy.colls.has_path', 'funcy.calc.CacheMemory.__setitem__', 'funcy.colls.zip_values', 'funcy.decorators.Call.__str__', 'funcy.colls.zip_dicts', 'funcy.decorators.has_1pos_and_kwonly', 'funcy.calc.CacheMemory.expire', 'funcy.calc.memoize', 'funcy.calc.SkipMemoization', 'funcy.flow.throttle', 'funcy.calc.CacheMemory', 'funcy._inspect.get_spec', 'funcy._inspect._sig_to_spec', 'funcy.decorators.decorator', 'funcy.calc.CacheMemory.clear', 'funcy.flow._ensure_exceptable', 'funcy.flow.reraise', 'funcy.funcs.curry', 'funcy.decorators.has_single_arg', 'funcy.calc.CacheMemory.__init__', 'funcy.flow.limit_error_rate', 'funcy.calc._memory_decorator', 'funcy.funcs.autocurry', 'funcy.decorators.Call', 'funcy.calc.SkipMemory', 'funcy.calc.CacheMemory.__getitem__', 'funcy.colls.del_in', 'funcy.decorators.Call.__repr__', 'funcy.calc.cache', 'funcy.flow._is_exception_type', 'funcy.funcs.rcurry']

As for other packages, the APIs of @outside_package_name are called by funcy in the call graph and the dependencies on these packages also stay the same in our suggested versions, thus avoiding any outside conflict.

Therefore, we believe that it is quite safe to loose your dependency on funcy from "funcy==1.15" to "funcy>=1.15,<=1.17". This will improve the applicability of detect-waste and reduce the possibility of any further dependency conflict with other projects/packages.