Using a custom database

[oxgr]

I'm trying to use the CLI tool and while it's useful, it's a little cumbersome to find out that every addon isn't in the database and needs an extra step of vetting through multiple hits in a Github query.

With a little script, I scraped the ofxaddons.com website to use their list of automatically retrieved, but manually curated addons and now I have a .json file with over 2000 addons with names, authors, and URLs. I saw that the README mentions configuring locally for custom databases, but I can't seem to locate where a database should be stored or where it's referenced in the code.

How can I use a custom database? Ideally, a package manager's database would be centralised, so would it be helpful to coordinate with ofxaddons.com to somehow consolidate both databases?

[thomasgeissl]

hey, thanks for reaching out.
I am currently working on an update with a proper GUI.
the readme is a bit outdated. the current version does not require a config step and automatically loads this database: https://github.com/thomasgeissl/ofPackageManager/blob/master/ofPackages.json
and it should be downloaded to ~/.ofPackageManager/ofPackages.json
unfortunately, I broke it with I think with one of the last commits, ofxGit2 crashes when cloning a repo, will have a deeper look soon.

which version are you using? Did you install it via brew?

We were discussing the database a few times, and the more I think about it, I like to keep the database quite small and use the GitHub search functionality. I think processing for instance handles their library manager in a similar way. I think a curated small database and search functions (GitHub, GitLab, google code, ...) is the way to go. But I am happy to discuss this and work on it when the other bug is fixed.

here is a screenshot after typing the query and hitting enter. It is way easier with the GUI.

maybe the interactions on the CLI just have to be improved, e.g. better defaults, proposing the one addon with the most stars (maybe that's already the case, but I am sure that there are ways to improve it)

[oxgr]

Yes, I installed CLI via brew and downloaded the release version as well. CLI is v0.1.0 and Release is v0.2.2. Perhaps the CLI has been changed between versions. New app doesn't work in command line because of path errors, but maybe I just need to run the install script again.

The GUI works, though it does present the same obstacles as the CLI tool (sifting through repos, when there's only one obvious match). CLI doesn't propose a single "most likely" addon yet, but even then, I'm hoping for the most simple interactionless install command since my targets are both for an automated CI build with Github Actions and stressed out devs onsite. Something like npm install? Better defaults is a good start as well as allowing interactions only with flags.

Replacing the database does help. Installs using a name mostly go through on the first try. With the amount addons in the ofxaddons.com list, I'm sure it covers most, if not all, of the mature ones. ofPackageManager install still seems to ignore ofx entries in regular syntax and doesn't check global addons either. Here is the JSON in case anyone is interested.

ofPackages_ofxaddons.com.json.zip

Perhaps expecting a central database like npm requires overhead maintenance of the namespace that would be too much work for a small package manager for a relatively niche creative coding framework vs an industry environment/language. Still, it would be ideal if a simple ofPackageManager install && make can get an app rolling right away.

I could look into helping improve the CLI tool if I can get the app to compile. There's a bunch of errors with ofxStateMachine that I can't exactly decipher, but that's another issue altogether.

[thomasgeissl]

what are the issues you experiencing with ofxStateMachine. I am more than happy to get these fixed, so you can join in improving the package manager.

So what you are saying is that you wanna use the ofPackageManager on projects, not set up with ofPackageManager where no urls and commits are stored in the addons.make?
I agree that this would be nice, but since most old projects use global addons it will be quite some work to get this fixed, especially the edge cases, e.g. addon is already cloned, but at a different commit.
The install should run through for projects being set up with ofPackageManager.

maybe it makes more sense to work on package feature, which move global addons to local ones and updates the addons.make file. this could be added to the bash version as well, so people can package their old projects and republish them. not sure this all makes sense, just brainstorming a bit here.

What version of oF are you using to compile it?
And does the example shipped with ofxStateMachine compile for you?