[discussing] Thought about packages & bundles

JulienTant commented 11 years ago

When i built a website with Laravel 3, i often "cut" parts of my application into bundles. Laravel 3 bundles was easy to create, it was just about creating a folder and write a line of code in a file.

Now I look into Laravel 4, and I really love the way we can easily import a package and it's dependencies trough Composer. The only thing that i can't easily solve is the thing I descrive above : Is Laravel 4 package system adapted to create a simple, private and non generic bundle. And i can't find an answer for now, so i'll first say no.

And that's what makes me think me about it : should we put bundles [ =~ bricks of our application ] and package [ =~ tools for our application ] in the same basket ? I'm not sure it's a good idea.

A solution may be a "Symfony2.* like" system, where packages are in vendor/, and developer bundles are in a "src/" folder.

Then you can still :

import package via composer, create new composer package with the workbench
and now create a specific bundle for your application, with maybe a new artisan command, something like php artisan bundle:generate :

What is vendor name of the bundle? aosix What is the bundle name? blog

Then it will create src/aosix/blog, with inside the same stuff that workbench import when we try to create a new composer package, but without any composer related stuff.

Don't hesitate to tell me if i'm missing something, maybe there's a simple way to do what i'm trying to do, maybe all of this doesn't make any sense for you, or maybe you agree with this solution.

bencorlett commented 11 years ago

You can use either workbench for packages, or Cartalyst have a Extensions package nearing release which does exactly what you're saying, separates your app into modular, extensible sections.

taylorotwell commented 11 years ago

Really all that is required to do is simply creating a folder named "bundles" in your application and registering whatever auto-loading you want in the composer.json file. There isn't any extra framework construct needed to allow this.

franzliedke commented 11 years ago

Also, check out Satis which allows you to host Composer packages privately.

bencorlett commented 11 years ago

It's great. On 02/04/2013, at 8:53 PM, Franz Liedke notifications@github.com wrote:

Also, check out Satis which allows you to host Composer packages privately.

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

JulienTant commented 11 years ago

Satis is IMO a heavy solution for a small problem. The simple solution provided by Taylor is "ok", but i'm looking forward to the Cartalyst Extension package. Thanks a lot guys.

bencorlett commented 11 years ago

@AoSiX, I'm actually the author of that package, we're extremely close to announcing it as well. We're using it in our upcoming Platform 2 and it works a charm.

We actually use Satis to distribute all of our extensions as composer packages, however this isn't required at all for our Extensions package to work, it just plays nicely :)

rickmills commented 11 years ago

Just to add to this discussion. @taylorotwell is there an alternative to your suggestion of simply adding another folder? The reason I ask is that if you're distributing your final app and allowing people to 'plug in' their own little MVC packages, its impossible to do so without every host having composer installed.

So taking that and putting it into a (crude) example, lets say you have a blog system with 'addons' (or 'plugins', 'modules', whatever you want to call it). If a user wants to add one of these addons to their system they cant do that unless they first install composer, and run composer dump-autoload, which really isnt an option if you're distributing this little blog system (ala wordpress style).

Is there any alternative or is this a limitation that cant be overcome? I know a few people have tried out various modular/hmvc options on the forums but they all have pretty glaring flaws where they are trying to dance around the composer issue.

taylorotwell commented 11 years ago

I'm sure you could concoct your own bundle like system that doesn't use composer if you wanted to.

On Jun 11, 2013, at 6:06 AM, Rick Mills notifications@github.com wrote:

Just to add to this discussion. @taylorotwell is there an alternative to your suggestion of simply adding another folder? The reason I ask is that if you're distributing your final app and allowing people to 'plug in' their own little MVC packages, its impossible to do so without every host having composer installed.

So taking that and putting it into a (crude) example, lets say you have a blog system with 'addons' (or 'plugins', 'modules', whatever you want to call it). If a user wants to add one of these addons to their system they cant do that unless they first install composer, and run composer dump-autoload, which really isnt an option if you're distributing this little blog system (ala wordpress style).

Is there any alternative or is this a limitation that cant be overcome? I know a few people have tried out various modular/hmvc options on the forums but they all have pretty glaring flaws where they are trying to dance around the composer issue.

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

JulienTant commented 11 years ago

Hi,

This is how i finally handle that :

I created a /src folder at the root of my installation, and i declared this folder into the path file ( /bootstrap/paths.php )
I updated composer.json to handle my namespace "Lvlfr" in the "src" folder
i created a script which is loaded by start.php, and its goal is to "load" my bundles : https://github.com/laravel-france/website/blob/develop/app/modules.php ( i'm sure there is a better way to do this.. but for now it's ok )

It works fine. I just don't know how to handle migrations, but for the moment i don't need migration. Maybe i'll store all the migrations into the app/ folder

crynobone commented 11 years ago

I have yet to find anything that can't be done with package that we were used to be able to do as bundle. Package now can dictate route (I consider that as an improvement instead of disadvantage).
Create a folder anywhere (and follow how you would do it in workbench), add it in app composer.json, create a package Service Provider and you have yourselves a bundled package. No additional hack required.

steadweb commented 11 years ago

I'm using the workbench at the moment to create my own "bundles". I find these work like a charm. My only concern is that the packages are private and shouldn't be distributed to packagist.

As long as I don't publish them, am I correct in saying they won't be shared? These are more app specific modules.

Satis is my next option to look at.

bencorlett commented 11 years ago

If you're not redistributing your apps (even internally), workbench is great.

If you're redistributing them in your other apps, internally etc, satis is your go-to. It seriously takes like 10 mins to setup.

On 21/06/2013, at 9:03 AM, Luke Steadman notifications@github.com wrote:

I'm using the workbench at the moment to create my own "bundles". I find these work like a charm. My only concern is that the packages are private and shouldn't be distributed to packagist.

As long as I don't publish them, am I correct in saying they won't be shared? These are more app specific modules.

Satis is my next option to look at.

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

laravel / framework

[discussing] Thought about packages & bundles #710