I think fanr could be more intelligent in the way it handles transitive dependencies when installing pods. Here's an example I recently stumbled upon...
And we attempt to install bar, then we would receive an error:
C:\> fanr install -r http://example.com/fanr/ bar
ERROR: install command failed
Cannot meet dependency 'foo 2.0.7 - 2.0' for 'bar'
use -errTrace for full stack trace
Whereas the repository does contain a valid pod dependency of foo 2.0.8.
Sniffing the HTTP requests revealed that fanr sends a query for the exact pod version foo 2.0.7 - which naturally doesn't exist.
fanr may have done this for performance reasons (because it's not unreasonable to expect the pod to exist), but if it doesn't then it'd be nice if fanr could then query the repository for other valid pods in the accepted range - foo 2.0.7 - 2.0
brianMon 6 Jul 2015
It might be because of InstallCmd around line 112:
// query the repo, eventually it would more optimized to
// batch as many dependency queries as possible together
newInstall := repo.query("$d.name $d.version", 1).first
If you try changing that d.version to be the full dependency string does that fix it?
SlimerDudeTue 7 Jul 2015
Hi, yep this does fix it:
// query the repo, eventually it would more optimized to
// batch as many dependency queries as possible together
newInstall := repo.query(d.toStr, 1).first
But it also changes the default resolution too...
Whereas before fanr would install for the lowest compatible version, with the above change it now installs the highest.
If my example has multiple versions of foo:
foo 2.0.10
foo 2.0.8
foo 2.0.7
fanr now asks for foo 2.0.7 - 2.0, and because repositories return pods in descending order, foo 2.0.10 is at the top, is first in the list and gets chosen to be installed.
I believe installing the latest pod versions is probably more desirable, but it may also highlight / break some existing installs somewhere!
brianTue 7 Jul 2015
Thanks for tesintg - I would imagine that installing the latest version is exactly what we want. I pushed that change.
SlimerDude Mon 6 Jul 2015
I think
fanr
could be more intelligent in the way it handles transitive dependencies when installing pods. Here's an example I recently stumbled upon...Lets say we have these 2 pods:
If a remote repository has these pod versions:
And we attempt to install
bar
, then we would receive an error:Whereas the repository does contain a valid pod dependency of
foo 2.0.8
.Sniffing the HTTP requests revealed that fanr sends a query for the exact pod version
foo 2.0.7
- which naturally doesn't exist.fanr may have done this for performance reasons (because it's not unreasonable to expect the pod to exist), but if it doesn't then it'd be nice if fanr could then query the repository for other valid pods in the accepted range -
foo 2.0.7 - 2.0
brian Mon 6 Jul 2015
It might be because of InstallCmd around line 112:
If you try changing that d.version to be the full dependency string does that fix it?
SlimerDude Tue 7 Jul 2015
Hi, yep this does fix it:
But it also changes the default resolution too...
Whereas before fanr would install for the lowest compatible version, with the above change it now installs the highest.
If my example has multiple versions of
foo
:fanr now asks for
foo 2.0.7 - 2.0
, and because repositories return pods in descending order,foo 2.0.10
is at the top, is first in the list and gets chosen to be installed.I believe installing the latest pod versions is probably more desirable, but it may also highlight / break some existing installs somewhere!
brian Tue 7 Jul 2015
Thanks for tesintg - I would imagine that installing the latest version is exactly what we want. I pushed that change.