Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split Registries management to a separate repository #206

Open
AntoineDao opened this issue Dec 8, 2020 · 3 comments
Open

Split Registries management to a separate repository #206

AntoineDao opened this issue Dec 8, 2020 · 3 comments
Labels
question Further information is requested

Comments

@AntoineDao
Copy link
Member

AntoineDao commented Dec 8, 2020

@mostaphaRoudsari brought this up briefly during a call but did not have time to explain his thoughts fully. Would you mind explaining in a bit more detail what your thinking was here so we can keep track of this development proposal?

@AntoineDao AntoineDao added the question Further information is requested label Dec 8, 2020
@mostaphaRoudsari
Copy link
Member

From showing and explaining queenbee to a handful number of people I felt it will be helpful to separate the package manager functionalities from the queenbee schemas. The package manager part will provide functionalities to package, pull, ... the Queenbee recipes and plugins while Queenbee provides the functionalities for writing the recipes, plugins and plugin functions.

Maybe we can call it Beehive or Queenbee package manager -> qpm!

@AntoineDao
Copy link
Member Author

AntoineDao commented Dec 8, 2020

I like the idea. It would provide a nice abstraction to work from also. Are we ok parking this issue for now and you or I can sift through the codebase to figure out how straightforward it will be to extract this stuff?

PS: I really want to call it Beehive but Queenbee Package Manager is probably more sensible... 🙃

@mostaphaRoudsari
Copy link
Member

Are we ok parking this issue for now and you or I can sift through the codebase to figure out how straightforward it will be to extract this stuff?

I would say so. Let's do it after the early access. I think it is nice to have but it is not critical right now.

The functionalities are almost separate so it shouldn't be that hard to separate them into its own package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants