ofPackageManager: pre-release for osx testing

I just merged it.
it is not yet super stable (not yet chekcing if json properties exist) and not documented, but by checking the test node file you should get an idea.
It supports installing packages from the addons.make file, installing them by id, github handle, url (with specified tag or commit), adding packages to the addons.amke file and searching the database and github.
Hope that helps.

i updated it on brew too.
brew upgrade ofpackagemanager

I was thinking to link the two to avoid having to compile another tool separately.
But I think having them separate does make more sense.

I wonder if the package manager could be just another tab in the project generator electron app?
The interactivity Y/N could probably be handled with dialogs and then the selection could probably be handled with dropdowns.

I’ll give it a whirl with brew first before I speculate more :slight_smile:

i think i removed all the interactive parts from the json based interface.
the default cli is more verbose and probably quite difficult to parse.

the cli is documented here: https://thomasgeissl.github.io/ofPackageManager
i try to document the json interface these days.
ofPackageManager "{\"type\": \"GETVERSION\"}"

let me know if you run into any problems or if there is anything missing.

i updated it again: brew upgrade ofpackagemanager
docs for the json interface can be found here: https://github.com/thomasgeissl/ofPackageManager/blob/master/docs/json.md

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)

config

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

generation

  • 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).

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

T

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.


5 Likes

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:

ofxA
local_addons/ofxB
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.
    e.g.
 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
        https://github.com/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:
local_addons/ofxMidiMapper#https://github.com/thomasgeissl/ofxMidiMapper.git@e338553c6
[ 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.