Composer support & stars

happyDemon commented 11 years ago

With Kohana also available on Packagist nowadays and modules also floating around there, maybe it would be nice to add an icon or link on a module's page that shows if it supports installation through composer.

You could easily check by looking for a composer.json in the repo's root.

Kohana-modules.com was created before the concept of stars existed, I was wondering if we could also add this to the site as a little extra info on a repo, since it does show interest in the module.

happyDemon commented 11 years ago

I have some code ready to push after I finish testing it out

ahutchings commented 11 years ago

Both of those sound great, send a pull request whenever you're ready.

happyDemon commented 11 years ago

I made an initial commit, but I'd still like to expand the composer support a bit.

For modules that do support composer I would still need to get the package's name out of their composer.json (at the moment it's just lowercase / since that's the general standard).

Maybe for modules (made for KO 3.3) that don't support composer out of the box, we might be able to distribute them ourselves, since we're already keeping track of tagged releases we'll be able to generate our own master packages.json (http://getcomposer.org/doc/05-repositories.md#hosting-your-own) as a Kohana-specific ecosystem. the packages.json would need to be stored at the root of the domain so developers who want to make use of it would only need to add "http://kohana-modules.com" to their list of repositories to get access to all the modules that don't support composer out of the box.

I have been adding them manually to my project's composer.json and it's a hassle when working on multiple projects, it would be nice to have them in one spot and kohana-modules.com would be perfect for it.

ahutchings commented 11 years ago

That's interesting - what would be involved in setting up the domain as a composer repo? Just generating the package.json? Would we have to support a composer search feature, or would that be handled by the composer client using our static package file/files? Would module compatibility be involved at all in generating the package.json?

Would you provide an example of what the packages.json file would look like?

happyDemon commented 11 years ago

All we would have to do is generate a packages.json and host it at the root of the domain. Here's an example, I have done this through satis (seems the easiest option): I used this file to store the repo's I want to compile in the package.json: http://ktt-happydemon.rhcloud.com/satis.json I ran "php bin/satis build satis.json ./" Which created: http://ktt-happydemon.rhcloud.com/index.html and http://ktt-happydemon.rhcloud.com/packages.json

As you can see on index.html (which isn't really needed, it's just a nice overview), the user would need to add the root domain to his repositories with 'composer' as type.

When they need a package composer will download our packages.json, look through it, and download the package from github, if found, otherwise it'll go and search packagist (or other developer-defined repos) So the search feature isn't something we'd need to worry about.

We cannot implement module dependencies for modules that don't have their own composer.json, we can only serve the modules as they are presented to us. I would also think about onlysupporting Kohana 3.3 modules (those without composer.json defined in their repo) at the start (since that release came with composer bundled in the install).

Maybe we should add a guide on kohana-modules.com on enabling composer support, installing modules through composer and maybe even packaging modules for composer.

The modules that do have a composer.json file, we could index though, making it possible for us to also offer a keyword-based search, maybe switch out Github's description with the description they define in their composer.json file.

ahutchings commented 11 years ago

Sounds like offering a composer repo for modules that aren't already indexed on packagist will be the major benefit of this, correct? I'd say let's go ahead with that as the primary goal. To complete that feature will require:

Generating satis.json on module sync/import, then subsequently running satis to generate the static packages.json that will live at the domain root.
Create a page documenting how to add kohana-modules.com as a composer repo, and maybe a little info on how to install kohana modules through composer. I don't want to duplicate generic composer docs that can be found elsewhere, but kohana module specific stuff would be good.

Did I miss anything? Would there be any reason to include modules that already have a composer.json in our composer repo? I'm assuming those can already be installed through packagist.

happyDemon commented 11 years ago

with the pull request I added a task that can be run as composer:sync, which can be called after module:import and module:sync. seemed easier.

Still need to add this at the end of those commands if we don't want to manually run the command:

Minion_Task::factory(array(
    'task' => 'composer:sync'
))->execute();

Only modules without a composer.json are compiled with satis, since they're probably already hosted on packagist.

My code could still be expanded a bit, since the versions of the repo are static at the moment. I think it might be best, that when syncing, we also check if there were new commits to the repo. If so, we could up the version number in satis.json with the commit's sha as reference, so the packages are actually update-able.

happyDemon commented 11 years ago

There we go, added an extra commit so can 'version' the modules.

We do this by storing the commit's sha in a separate table, if we don't have the new commit's sha, we'll add a version.

These are never major versions, so if developers want to auto-update the packages we server they could always define their package requirement as "developer/package": "1.*"

This should complete the basic Satis support and serving modules through composer.

All that's left to do is write out the guide(s) and maybe change the controller_module::action_show template to reflect the changes made today.

ahutchings commented 10 years ago

Sorry, this completely dropped off my radar. Is this still something you want merged in? What work is outstanding?

happyDemon commented 10 years ago

I actually have a big commit waiting to be pushed. I think it's fine if you close this and forget about it xD

If you're interested I made a topic in the new Kohana forums: http://discourse.kohanaframework.org/t/kohana-modules-com-sugestions/167

ahutchings commented 10 years ago

Sounds good. Looking forward to the pull request!

ahutchings / kohana-modules.com

Composer support & stars #35