Hi Sean, Sean Whitton <spwhitton@spwhitton.name> writes: > Hello, > > On Sat 14 Mar 2020 at 02:13PM -06, Nicholas D Steeves wrote: > >> Hi team, >> >> I'm not a Helm user, so I'm not sure what the correct resolution to this >> issue is: >> >> "helm weakly require[s] >> wgrep-helm. https://github.com/emacs-helm/helm/blob/master/helm-grep.el#L26"; >> >> https://github.com/mhayashi1120/Emacs-wgrep/pull/70 >> >> but helm-wgrep appears to require helm. >> >> To my eyes this initially looked like a missing requires in helm-grep, >> which is why I filed that PR, but now I'm not sure...it still feels like >> a problem that should be fixed upstream (both in Helm and helm-wgrep). >> If this is par for the course, for Helm, and it's not an actionable bug, >> then I'm not sure what to do. > > Why not just follow upstream and have helm-wgrep Depend on helm and helm > Suggest helm-wgrep? > It wouldn't be following upstream, because helm-wgrep does not depend on Helm: https://melpa.org/#/wgrep-helm Upstream rejected my addition of 'Package-Requires: (helm "1.4.0")' because my "patch does not cause problem right away although, I don't want cyclic reference for helm to avoid loading problem." Is this a package.el dependency resolution limitation and load order problem our glorious dpkg-using systems are immune to? As for the "cyclic reference", helm-grep uses a different code path when wgrep-helm is installed, but wgrep-helm does not function at all without helm. Please confirm if this seems like a case where it's best to digress from upstream and implement a Debian-specific solution using our own dep resolution. I agree with your solution and have been thinking along similar lines, and just want to learn from others' experience with weird circular dependencies in Emacs packages...for all I know this is par for the course for Helm-related packages... Thank you, Nicholas
Attachment:
signature.asc
Description: PGP signature