search

pingpong-labs / modules

Laravel 5 Modules
https://pingpong-labs.github.io/docs/modules.html
BSD 3-Clause "New" or "Revised" License
577 stars 151 forks source link

module:install for non github #53

Open thujohn opened 9 years ago

thujohn commented 9 years ago

Hi.

I just saw the command module:install but it is github only. Have you planned to allow others like bitbucket or custom installation ?

gravitano commented 9 years ago

Hi, I also have a plan like that. I also have a plan to create a 'laravel modules manager' like packagist.

thujohn commented 9 years ago

I'm looking forward to it :)

nWidart commented 9 years ago

This would be indeed very helpful to the AsgardCms too.

nWidart commented 9 years ago

I've opted for using the composer/installers to install modules and themes for pingpong/modules. This way composer can handle the versions of modules. And all modules/themes are on packagist.

noxify commented 9 years ago

Based on your code @nWidart - here the snippet. I love the idea to add new modules via composer - gives us the best flexibility.

Alternative we can create a plugin manager like wordpress has, but this is a bit overkill :)

<?php

/**
 * Example based on the AsgardInstaller
 * https://github.com/composer/installers/blob/master/src/Composer/Installers/AsgardInstaller.php
 */
namespace Composer\Installers;

class PingPongInstaller extends BaseInstaller
{
    protected $locations = array(
        'module' => 'Modules/{$name}/'
    );
    /**
     * Format package name.
     *
     * For package type pingpong-module, cut off a trailing '-module' if present.
     * 
     */
    public function inflectPackageVars($vars)
    {
        if ($vars['type'] === 'pingpong-module') {
            return $this->inflectModuleVars($vars);
        }

        return $vars;
    }
    protected function inflectModuleVars($vars)
    {
        $vars['name'] = ucfirst(preg_replace('/-module/', '', $vars['name']));
        return $vars;
    }

}
nWidart commented 9 years ago

It's nice, but I don't know if making a 'pingpong-module' installer, default for everyone is a good idea. For instance I like to put the modules in the rootdir/Modules, but maybe others have them in app/Modules, or somewhere else completely different.

On the other hand, it would provide a nice default, and that way modules can be handled via composer which is always better. And if people want an other location for their modules, they create a custom installer.

At the end it may be worth it to create a default installer.

noxify commented 9 years ago

Hi,

yes, you're right. Only in case that the application is using the default setting rootdir/Modules, it's possible to use the composer installer.

I searched a bit around and found this interest package: https://github.com/KnpLabs/packagist-api

My idea is, to create a new table like modules and saving all needed information for the current version.

In the frist version, it should be enough to create a small artisan command like php artisan modules:check_updates.

This will check all installed modules against the packagist api. If there is a new version available, we will do some magic stuff :)

There is also an command like

I will give it a try this evening :)

noxify commented 9 years ago

To save you an hour or two - here the gist with the code snippet ;) https://gist.github.com/noxify/44855c222050e973d427

Search (using search.json)

artisan packagist:search <search_string> --tag=<tag_name> --tag=<tag_name> --type=<type> --vendor=<vendor>

List (using list.json)

artisan packagist:list  --tag=<tag_name> --tag=<tag_name> --type=<type> --vendor=<vendor>

Details (using packages/.json)

artisan packagist:detail <package_name>
gravitano commented 9 years ago

Maybe the better way is scan vendor directory. how do you think about this?https://github.com/pingpong-labs/modules/commit/2ce4d58b34046ffbcfe7e99074dd919f9d956e60.

With this function, this package will scan the vendor directory and if there is an identifier, we will assume in that directory there is a module that created using this package. In this case the identifier is module.json file.

noxify commented 9 years ago

Hi,

Sounds very good. I like this idea.

Mit freundlichen Grüßen | kind regards Marcus Reinhardt

Email m.reinhardt@y-im.de || Office +49 6144 8028815 || Mobile +49 151 11334215

yim OHG | yourguide information management | Neckarstraße 44 | D-65462 Ginsheim

Web www.y-im.de | Office +49 6144 802880 | Fax +49 6144 8028890 |Email info@y-im.de Amtsgericht Darmstadt | Registerabteilung Groß-Gerau | HRA 53351 | Gesellschafter Petra & Frank Jurgeit

Am 14.12.2014 um 11:13 schrieb Gravitano notifications@github.com:

Maybe the better way is scan vendor directory. how do you think about this?2ce4d58.

With this function, this package will scan the vendor directory and if there is an identifier, we will assume in that directory there is a module that created using this package. In this case the identifier is module.json file.

— Reply to this email directly or view it on GitHub.

nWidart commented 9 years ago

Sounds scary in terms of performance hit. I think already as it is now the active modules should be cached to remove the io operation. With the cache it would be a lot better. Maybe make the checking of the vendor folder optional.

noxify commented 9 years ago

This Package did it in a good way.

https://github.com/creolab/laravel-modules/

It allows multiple directories and also an Option to cache Module paths:)

Maybe we can get some inpirations ;)

gravitano commented 9 years ago

Yes, the package was really inspired me. Yesterday I have added a caching feature. https://github.com/pingpong-labs/modules/commit/2c6db586b3d2e6bd81d49b0ea017128d66731f8b

gravitano commented 9 years ago

@thujohn : In the last stable release of this package, I've added new improvement for module:install command. Now, you can directly install your module from 3 types, github, bitbucket or composer (default).