ofPackageManager: pre-release for osx testing

hey @theo,

i started to write a little electron frontend for the package manager. It still needs lot of work on the ui and the final project generation needs to be fixed. I could not make the project generator update the project.

Here is a first draft, so far it does:

open or new

  • create a new project (command line project generator called from electron)
  • opens an existing project (parsing the addons.make file via command line package manager called from electron)


  • add, remove already installed addons (via web ui)
  • install missing or new addons (command line package manager called from electron)


  • add packages to the addons.make file (command line package manager called from electron)
  • i am struggling with: finally update exiting project (command line project generator called from electron).

Do you think that approach is fine?

I think it should be possible to add all the features currently provided by the the project generator frontend. But i wanted to coordinate with you and also with @zach and anyone else who has opinions, ideas and doubts. I think it is quite difficult to merge the package manager frontend with current project generator frontend, as it uses a different ui framework (react).

Here is the code for the frontend.
It uses electron, react, redux, material ui.


i think it creates/updates/updates multiple now corrently.
i am not very elegantly calling the command line pg with an addon list and delete the addons.make file and regenerate it with the package manager.

if someone wants to give it a try, the UI is now much cleaner.
there are still some smaller bugs and things to be improved, but it is already quite usable.


Hey Thomas! this looks really neat. I’ll try it now.
Do you have an already built front end UI or do I need to build it?

i have not uploaded a build yet. you can find the insturctions in the readme.
it also needs the projectGenerator and ofPackageManager cli tools installed. ofPackageManager can be installed via brew.
let me know if you encounter any issues.

yes. was able to build it. I’ll come with some more feedback later. :slight_smile:

1 Like

my feedback so far is maybe just two things:

  1. Minimal setting of user paths would be amazing. Right now there are quite a lot that need to be set here. Maybe setting smart defaults automatically makes sense. Then people can edit if needed.
  2. I wonder if we need the local_addons distinction? Without it things become a lot simpler: Just set the location of your OF folder. If the cmd line PG needs building it can do that or detect it. It can use the addons/ folder by default for installing addons.

In general anything that streamlines the setup/usage is great.

It also gets me wondering if we could move from a cpp command line project generator to something that doesn’t need compiling like python? Probably would be a huge amount of work to port over, but then would make tools like this so much easier to make and no build steps needed on each platform.

hey theo, thanks for the feedback.
i agree with 1. and i think this can be done in a smarter way. if the package manager is bundled with the pg and package manager cli tools, as well as the database, then i guess it only needs to know the openframeworks path.
2. i strongly believe that local_addons is the way to go. but for the transition phase i would like to default it to the global addons path. and let the users optionally select to install locally in the install modal.

Ace work! Though I found the implementation and abstraction a bit confusing. In yarn and npm the install cmd reads a config and then fills the local dependency folder, but here it wasn’t too clear where things are coming from and going to.

A situation I’m often in is trying to juggle forks and commits of addons with addons I’m working on locally, and then there not being an easy way to have an overview of what’s what in a project (ie. “source of truth”).

A package.json could help to hold all the user readable / editable information and metadata like version no, author etc. With the addons.make file acting more like a node_modules equivalency once ofPackageManager has done its thing.

Also tangentially relates to the addons_config.mk, which I think would be better served by a JSON file, and could also specify package manager-friendly dependencies…

Maybe something like this

	“name”: “example-app”,
	“version”: “1.0.0”,
	“addons”: {
		“ofxA”: “ofxA”, 
		“ofxB”: “../../../addons/ofxB”, 
		“ofxC”: “github.com/user/ofxC” 
$ ofPackageManager install 
> Installing locally. Overwrite the local_addons folder? y/n
$ ofPackageManager install global
> ofxC already exists in addons. Install locally instead? y/n

hey, thanks for the feedback.

The package manager reads the addons.make file and then downloads the dependencies into your local_addons or openFrameworks/addons directory. The packagemanager adds url and commit hash as a comment to the respective line in the addons.make file.

package.json <=> addons.make
node_modules <=> local_addons

The idea behind that was that an ofPackageManagerised project is compatible with other oF projects. Or seeing it from the other side, ofPackageManager works in theory even with unpackaged projects. It will try to find and download any addon listed in the addons.make file.

I agree that a json based solution can be more verbose and programmer readable. But it is probably not that easy to integrate into the make build system. And letting the package manager store its information in json format, then generating make files and then letting the project generator generate ide project files also did not seem right.

What would be needed to make the flow clearer? Better console output? Better readme?

hope that clarifies things a bit.

Ah thank you, that makes good sense.

When I saw the generated comment I assumed it was that; so to make the flow clearer I would add documentation that explains how comments can specify particulars for an addon, and some examples of common or peculiar user flows. My ideal would be to have this reduce complexity rather than add it (I’m terrible at remembering CLI commands), so in practice that would mean trusting only the ofPackageManager install command to get everything prepared for a project. For example in an addons.make like this:

local_addons/ofxC # @4f0e76
local_addons/ofxD # https://github.com/user/ofxD
local_addons/ofxE # https://github.com/user/ofxE@2f0e63

It would be awesome to have the CLI do:

ofxA > search for ofxA in addons folder, if not found run http search feature
ofxB > search for ofxB in addons folder, if not found run http search feature, copy locally
ofxC > search for ofxC in addons folder, if not found run http search feature, attempts clone at @commit, defaults to master HEAD
ofxC > clones locally
ofxD > clones locally

I hope this is not requesting more complex features, but rather my perspective is that the wizard structure works really nicely, so on this basis it is addons.make that defines things, followed by ofPackageManager handling them - and the rest of the CLI commands for special cases.

hey @autr, sorry for the late response.

I think you only need to commands, the first and most important one is install. The second one is the add command.

  • if you wanna install a package which is not found in the database, the cli will ask you if you wanna have a look on github.
 thomas.geissl@CT-MUC-ThomasGe  ~/libs/of_v0.11.0_osx_release/apps/packagemanager/ofPackageManager/scripts/test   master ●  ../../bin/ofPackageManager.app/Contents/MacOS/ofPackageManager install ofxMidiMapper            ✔  10207  09:54:28

[ notice ] install: Installing package: ofxMidiMapper locally
[  error ] search: Unfortunately ofxMidiMapper was not found in the database.
But it is probably available on github. Wanna give it a try? [y|n] (y) y
[ notice ] search: The following repositories contain ofxMidiMapper:
0: thomasgeissl/ofxMidiMapper
        stars: 2, open issues: 0, updated at: 2018-11-12T22:55:36Z, forks: 0, isFork: false

Do you wanna install any of them? [y|n] (y) y
Which one? Please enter the corresponding number. (0) 0
[ notice ] ofPackageManager: install package by url (https://github.com/thomasgeissl/ofxMidiMapper.git@latest to /Users/thomas.geissl/libs/of_v0.11.0_osx_release/apps/packagemanager/ofPackageManager/scripts/test/local_addons
[ notice ] install: Successfully cloned repo https://github.com/thomasgeissl/ofxMidiMapper.git
[ notice ] install: Successfully installed package:
[ notice ] ofPackageManager: successfully updated addons.make

[ notice ] Thanks for using ofPackageManager.
If you find a bug then please report it on the github issue tracker (https://github.com/thomasgeissl/ofPackageManager/issues).

See you soon.
  • If you manually clone an addon or modify it locally then you can run the add command.
    It will add/update url and hash in addons.make file.
 ● ?  rm addons.make                                                                                ✔  10211  10:00:58
 thomas.geissl@CT-MUC-ThomasGe  ~/libs/of_v0.11.0_osx_release/apps/packagemanager/ofPackageManager/scripts/test   master ● ?  ../../bin/ofPackageManager.app/Contents/MacOS/ofPackageManager add local_addons/ofxMidiMapper

[ notice ] ofPackageManager: successfully updated addons.make

[ notice ] Thanks for using ofPackageManager.
If you find a bug then please report it on the github issue tracker (https://github.com/thomasgeissl/ofPackageManager/issues).

See you soon.

 thomas.geissl@CT-MUC-ThomasGe  ~/libs/of_v0.11.0_osx_release/apps/packagemanager/ofPackageManager/scripts/test   master ● ?  cat addons.make                                                                      SIG(127) ↵  10213  10:01:13
local_addons/ofxMidiMapper #https://github.com/thomasgeissl/ofxMidiMapper.git@e338553c6% 

I still need work on better console outputs.
if i remember correctly you always need to specify url and hash in addons.make. Just the url or the hash wont work.

i hardly have to modify the addons.make file manually. And i think that should be the goal.

if you or anyone else is intersted in collaborating or disussing things, giving more feedback, we could also schedule a slack call.

heyho people,
i need your help again. i just updated the packagemanager and the frontend. and it needs to be tested.
also, i made the ofProjectGenerator cli installable via brew. The package manager frontend should now hopefully be signed and notarised.
I improved the configuration quite a bit, but that still needs to be tested on other machines.
I think it works the best if you install ofPackageManager and ofProjectGenerator first and run the config task and then open the frontend. It should hopefully pick up the paths automatically. If you run it the other way round, it should hopefully warn you.

brew tap thomasgeissl/tools
brew install ofpackagemanager
brew install ofprojectgenerator
# brew upgrade ofpackagemanager
# brew upgrade ofprojectgenerator


Feedback and bug fixes are very welcome.

there are also windows and linux versions of the frontend available, in case you manage to compile the cli on these platforms.

thanks to @prisonerjohn, i uploaded a windows build. could someone test if the frontend runs on windows without problems?
the steps are as follows.

  1. download ofPackageManager cli and add it to your path: (https://github.com/thomasgeissl/ofPackageManager/releases)
  2. configure ofPackageManager globally: ofPackageManager config -g
  3. download or compile projectGenerator cli and add it your path (should be included in the packages, e.g. path/to/of_v0.11.0_vs2017_release/projectGenerator-vs/resources/app/app/projectGenerator.EXE)
  4. download ofPackageManager-frontend and run it (https://github.com/thomasgeissl/ofPackageManager-frontend/releases)

the frontend tries to find both CLIs in the path, if not available you can edit the config at $HOME/.ofPackageManager/frontend.config.json or fix values via the frontend settings modal.

1 Like

Hey @thomasgeissl,

I am not able to get the front-end to find the command line on Windows. There is no frontend.config.json file in that folder, and I don’t see a settings modal either. The command line tool is on my %PATH%.

If you let me know which lines in the frontend code to look at, I can dig around to see what’s up.

here is the init function, which checks for the cli tools and generates the frontend config file.

btw the projectGenerator should be also added to path.
there is settings icon on the top right cornor.

here is my example config, you can save it to HOME/.ofPackageManager/frontend.config.json

  "defaultProjectPath": "/Users/thomas.geissl/libs/of_v0.11.0_osx_release/apps/myApps",
  "ofPackageManagerPath": "/usr/local/bin/ofPackageManager",
  "ofProjectGeneratorPath": "/usr/local/bin/projectGenerator",
  "showAdvancedFeatures": true,
  "showConsole": true,
  "verboseOutput": false

let me know if that solves the problem.

some small updates on osx. the frontend should be now installable via brew (cask) as well. could someone test if this works?

brew tap thomasgeissl/tools
brew install ofpackagemanager
#brew upgrade ofpackagemanager
brew install ofprojectgenerator
ofPackageManager config -g

brew cask install ofpackagemanagerfrontend

i updated it, it is getting stable and the interfaces is now much cleaner. the local addons panel is not shown if there are none available. the platform and template panel is shown if advanced features are enabled.

1 Like