-
Notifications
You must be signed in to change notification settings - Fork 279
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
RedBean extras, community participation/plugins #315
Comments
Submissions process (proposal)
Maintenance
|
👍 sounds good. |
When things get to this point, most of the time, I see people creating github organizations. So all plugins ecosystem would live inside that Redbean organization, side by side with Redbean project too. Examples: |
@marcioAlmada Yeah, but I think a single redbean-sugar repo would work best. That way, community collaborators can work closely together. Otherwise, you might end up with a multitude of repos that grow disconnected and where communication is unnecessarily hard. Question in general: What will the name be? Is my idea with the "sugar" and "coating" stuff compelling or do we use something more generic? |
@daviddeutsch I particularly prefer a single repository too, because in case of a Redbean internal plugin API change it's easier to update all plugins at once. About naming, I'm always inclined to less smart names, "RedbeanPlugins" is much easier for a newcomer to understand what's happening. But I'm happy with any decision. Bringing composer to the mix: I took a look at plugins already avalilable, it seems every plugin has i'ts own rb.php file... isn't it time to get a better composer support to avoid stuff like that? |
@daviddeutsch Another idea which came to my mind would be to create a Boilerplate Plugin as Github repo. The plugin shouldn't really do a lot useful stuff, but simply show off how plugin developers should model their own implementations.
for me personally that would be a tremendous help, since I'm pretty new to all those concepts and I guess others could use a nice guide too. Not to say that we encourage this way the use of set standards. |
@zewa666 The boilerplate idea is awesome. @daviddeutsch But if all plugins are going to live on the same main plugins repo, how will new plugins get imported into that main repo? Example: I have just started a plugin to implement issue #311, I'ts called redsql how could it be imported to that hypothetical plugins repository? |
@marcioAlmada You simply create a Pull Request that has a new directory we will probably have a structure set up like this:
That also makes it easy to assign responsiblity to a maintainer - they're simply responsible for their own directory. Likewise, it will make it easier in the future to use this in building distributions. @zewa666 I think this planning is actually the best way - lead by example. It's all nice and well to put together documentation, but if you can show people right away, if they can look into the discussions and see code repositories change as we make new decisions, that will be more helpful than a documentation that we might end up being too lazy to keep updated 😉. In the end, probably just the introduction to the redbean-extras repo would suffice to get you started on figuring things out for yourself. It will also help embedd people better into the community, I think. |
@daviddeutsch fully agree |
@daviddeutsch agree too + I would eliminate the categories folder (Query, Search) to keep namespaces smaller: instead of Repo would look like this:
Other requirements:
|
But in the middle of the track I had one other idea. Maybe we should create a repo that is just a composer meta package and would have only this:
composer.json <<< {
"name": "redbean/extra",
"type": "library",
"description": "Redbean sugar plugins",
"require" : {
"david/rx" : "~0.1",
"marcioAlmada/redsql" : "~0.1",
"zewa666/QEB" : "~0.1"
// etc...
}
} To add a new plugin, contributor would do a pull request to this repo, adding a new entry in require section. Main redbean repo would just need to add a dependency: {
"require" : {
"redbean/extra" : "~0.1"
}
} Advantages:
Disvantages:
Well, just an idea. Maybe it can inspire improvements on previous idea. |
I like the meta package approach. |
Just added a mount option to the phar-builder.
|
Bump! @gabordemooij Are you really going with the meta package approach? How can we help? |
I agree that the way to go is to have separate repositories with one main The main constraints that we're dealing with are the repository and composer path structures. The other consideration is more of a social/community consideration: It would be nice for everybody to maintain "their own" repository that is referenced as that makes things less centralized and I think depending on the number of extensions, having a central bug tracker etc. won't scale in the long run. Mostly what I'm worried about is that might end up making it harder to keep a common level of quality and communication between participating community members. But the technical roadblocks trump that. Composer/repository structure - might be solvable by using composer to ship a kind of installer in The other consideration is unit testing, because it would be kind of hard to manage clean testing if one plugin failure would block other tests. You could solve this with branches, of course, but that's another overhead that might not scale. So: {
"name": "gabordemooij/redbean-extra",
"type": "library",
"description": "Redbean Extra",
"suggest" : {
"david/rx" : "~0.1",
"marcioAlmada/redsql" : "~0.1",
"zewa666/QEB" : "~0.1"
// etc...
}
} Note the But I think the most important thing by far will be the documentation and here is where the original "let's collaborate on a single repo" aspect should still work out. Of course, all repos would have their own documentation, but the |
Then again... I've been looking at other projects to see how they're using composer (thanks for the links @marcioAlmada). I found laravels approach quite intriguing: laravel/composer.json Particularlly the way they use post-install commands. This somewhat ties back to my other idea of optimizing RedBean by using static compilation, basically transforming RB commands into plain SQL snippets during installation. So if Now, of course - with the way composer is set up, redbean plugins could always simply declare their own post-install actions, but maybe a common interface is still a good thing here. Hmm... |
@daviddeutsch It seems the post install command is executed only from the main composer.json. I guess that if there is a post install inside a composer.json below vendor folder it will not be executed. Hope it's not a problem. I also like how Sublime Packages are handled too. They have a channel.json file (like a composer.json file) and an application that list those packages https://sublime.wbond.net/ and shows documentations for each project (a glorified README.md system). With a "plugin channel", plugin owners would just need to follow specific guidelines to make plugin installation through composer automatic. The good news is that our plugin channel already exists, it's called composer 😄 so maybe we only need to reserve a composer vendor for community redbean plugins: |
@marcioAlmada Good info! And yeah, I guess that only calls all the more for an approach that is somewhat "managed" by the RB project. It's really just an additional convention. So a plain composer.json that "scripts": {
"post-install-cmd": [
"RedBean\Deploy::all"
] This triggers the real magic to happen - and it will also trigger The only thing we can never have is To sum up, a composer.json for a project using RB and RBe would look like so: {
"name": "daviddeutsch/mycustomsite",
"type": "website",
"description": "Just my custom site using RedBean and some other stuff",
"require" : {
"redbeanphp/redbeanphp" : "dev-master",
"redbeanphp/extras" : "dev-master",
"daviddeutsch/rx" : "dev-master"
// etc...
"scripts": {
"post-install-cmd": [
"RedBean\Deploy::all"
]
}
} Another neat thing with this approach, a thing I've been talking about with @gabordemooij - It would be nice to have some kind of an interactive redbean kickstart. So basically like a one-page html app (probably angular driven with a tiny php server backend) that would lead you through the setup interactively and plugins could also hook into that - say if you have not made up your mind yet, they could show you "hey, would you like to write RB queries like this?" and/or "the plugins you have selected can do the following stuff, now that you have them installed" and it could lead to more crazy stuff. |
Don't you think "post-install-cmd" usage is too much? Laravel is a framework and every new Laravel project uses an app skeleton as starting point, they have artisan which is a command line tool integrated with the framework, so there is an infrastructure behind it that reinforces the "framework culture" and peripheral knowledge to understand how it works. Too much for an ORM that will be attached to any kind of project IMMO. The most simple and effective idea right now looks like this:
|
Sounds nice but what would be the workaround for people not working with composer? |
It seems non composer users will have phar file available:
But I confess I don't know exactly how it will work. |
So, I think it makes sense to make this into a ticket. On the mailing list, we already talked a little about this. To recap:
The text was updated successfully, but these errors were encountered: