Simple dependency support

Question

Simple dependency support

XVilka opened this issue 6 years ago · comments

Allow to set the dependency following something like these rules

depends: qwe
depends: qwe < 0.4
depends: qwe <= 0.5
depends: qwe > 1.4.5
depends: qwe >= 1.5.6
depends: 5.5 > qwe <= 8.0

pancake · Answer 1 · Wed Jun 27 2018 21:28:23 GMT+0800 (China Standard Time)

Its already done

…

On 27 Jun 2018, at 11:20, Anton Kochkov ***@***.***> wrote: — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Anton Kochkov · Answer 2 · Tue Aug 20 2019 16:06:03 GMT+0800 (China Standard Time)

Not in r2pm.go

Quentin Barrand · Answer 3 · Tue Aug 20 2019 16:57:24 GMT+0800 (China Standard Time)

@XVilka then I think that packages with the git type should point to a specific reference - no point in adding a version property in the YAML file if the package is always fetching master.

Anton Kochkov · Answer 4 · Tue Aug 20 2019 17:08:42 GMT+0800 (China Standard Time)

@qbarrand agree, no need for this for git packages.

imyxh · Answer 5 · Tue Apr 21 2020 02:02:13 GMT+0800 (China Standard Time)

As far as I understand it, the r2pm repository is only designed to hold the latest version of each package at a time. If that's true, how can we have versioned dependencies? Tying packages to r2 versions (as proposed here) should fix most compatibility issues anyway, imo.

The cleanest (albeit pretty slow) solution I can think of when dependencies update themselves is this: let's say the user is on radare2-4.4.0, and installed foopkg-4.4.0 a month ago. Now they want to install barpkg-4.4.0, which depends: foopkg.

R2pm then has to reinstall barpkg's dependency (foopkg) to ensure that it is at the latest version that the package manager intends to install for the given r2 version. For example, if the git tag has moved to a newer commit, or a zip file has been updated. Then r2pm can install barpkg.

Downsides:

maintainers of barpkg have to ensure that their package for each r2 version maintains compatibility with the latest foopkg at that r2 version;
rebuilding foopkg might take some time, so if we ever reach a point where we have r2 packages recursively dependent on like >5 other packages it could get pretty slow.

Advantages:

the r2pm repo only has to hold one YAML file for each package, ever; {{ .R2Version }} takes care of upgrades.

Thoughts? If we want to avoid the downsides mentioned I think we pretty much have to start storing foopkg-4.4.0-1, foopkg-4.4.0-2, etc. as different packages on the same repo and it would get cluttered. Would be more of a system like python-pip and less of a simple/clean plugin manager.