ofPackageManager: pre-release for osx testing

hey arturo, i dont remember, where did you send me? do you mean the list above?

i would love to be independent from github, having a local database is one step. We should make sure that there is an easy way to update it regularly. Properties like number of stars, number of open issues or updated_at will change daily.
In addition to that i wanna keep the search on github.

I will test with the database you showed me last time. If i remember correctly it was still not clear how to work with forks and the way the database is currently parsed. I think i am using the filename as an ID.

oh, you are right i sent it to ellie but never to you i thought he might have sent you. can you send me an email? i don’t think i have yours

I sent it via slack, i think i should be small enough to send it via slack directly. thanks

I improved the search task a little bit. The search task is now interactive and more verbose. Hopefully not too annoying by asking at every search if you wanna install or continue searching on github.

./bin/ofPackageManager.app/Contents/MacOS/ofPackageManager search ofxTimeline
The following package was found in the database: 
{
    "author": "YCamInterlab",
    "cloneUrl": "https://github.com/YCAMInterlab/ofxTimeline.git",
    "license": "",
    "name": "ofxTimeline",
    "type": "addon",
    "website": "https://github.com/YCAMInterlab/ofxTimeline"
}
Do you want to install it? [y|n] (y) n
Okey-dokey, do you want to search it on github? [y|n] (y) y
[ notice ] search: The following repositories contain ofxTimeline:
0: YCAMInterlab/ofxTimeline
        https://github.com/YCAMInterlab/ofxTimeline
        stars: 244, open issues: 45, updated at: 2019-10-23T23:20:01Z, forks: 133, isFork: false

// ...
16: borg/ofxOpenALSoundPlayer
        https://github.com/borg/ofxOpenALSoundPlayer
        stars: 0, open issues: 0, updated at: 2017-11-10T19:02:13Z, forks: 1, isFork: false


Do you wanna install any of them? [y|n] (y) n
[ 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.

It is in the current master, but not yet in the releases.

1 Like

heyho,
i just did another release of the package manager.

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

the package manager now supports a local config. That means it will use the config file in your project, if there is none, it will recursively check the parent directory and fall back to the global config. Now you can have configs per project or per oF installation.

Please feel free to test and report bugs.

Also, it would be very helpful if someone wanna test and do a release on windows.

@thomasgeissl thanks for sharing this.

I was wondering what would be the easiest way to use this with the PG and thinking that maybe the first step might be to be able to link ofpackagemanager into the command line version of the PG ( https://github.com/openframeworks/projectGenerator/tree/master/commandLine ) as we are already compiling that for most platforms.

Would there be any barrier to doing that currently?

Then it would just be a matter of exposing some of the package manager functionality in the Electron frontend.

1 Like

hey @theo,

the first step for me is calling the command line pg from the package manager. That should be straight forward and i was already working on it today.

Then i would like to prepare the package manager to live next to the command line pg and be called form it or the electron frontend. A few steps are needed therefore.

  • passing config options instead of parsing them from a file (branch: feature/pg)
  • silencing outputs when called from another tool (otherwise it will be quite difficult to parse the results)
  • no interactive tasks, i guess there wont be a back and forth communication between the apps
  • proper interface, maybe json based: ofPackageManager {task: "install", ...}

libgit makes it a bit painful to compile the package manager on all platforms.
The interface part is done mostly in the main file. The core functionality lives in the app. I guess you could also use that part in the project generator. But i dont think that the code is clean enough yet and not sure how to maintain it in the future if the two apps are bound together.

I happy to collaborate and move this forward.

Do you think a json based interface like this one could work?

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.


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