Skip to content
This repository has been archived by the owner on Apr 21, 2021. It is now read-only.

Simple dependency support #1

Open
XVilka opened this issue Jun 27, 2018 · 5 comments
Open

Simple dependency support #1

XVilka opened this issue Jun 27, 2018 · 5 comments
Milestone

Comments

@XVilka
Copy link
Contributor

XVilka commented Jun 27, 2018

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
@radare

This comment has been minimized.

@XVilka

This comment has been minimized.

@qbarrand
Copy link
Collaborator

@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.

@XVilka
Copy link
Contributor Author

XVilka commented Aug 20, 2019

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

@XVilka XVilka added this to the 1.0 milestone Aug 21, 2019
@imyxh
Copy link

imyxh commented Apr 20, 2020

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants