Proposals (Political/Workflow) #4782
Officially support using Composer (instead of submodules) to start a new app
|Assignee:||Lorenzo Pisani||% Done:|
Following #4776 the official packages are all (as of 3.3.1) registered as composer packages on packagist. In that discussion, Zeelot said:
Should we do anything to support creating a new project with composer? Do we need to add something to the composer.json file in kohana/kohana http://dev.kohanaframework.org/issues/4776#note-8
We should look into being able to start a kohana app from composer directly in the future :) http://dev.kohanaframework.org/issues/4776#note-10
I think this makes sense, but as it stands the composer.json would conflict with the submodules in kohana/kohana. There are a couple of options I can think of:
Remove submodules from kohana/kohana and use composer exclusively¶
- composer install (can be) faster, more straightforward and easier to keep up to date.
- it's relatively easy to configure so that you always get either the corresponding stable packages for a release or the most recent dev packages if you want them - no more need to update submodule refs all the time
- no longer possible to explore the whole source (kohana/kohana + the official modules and system) on github - so not as easy to get an immediate view of the whole framework, or to dig around on web to find where things come from (does anyone else do that?)
- may mean a little bit of learning for people used to (and using) submodules
- would lose a bit of change tracking by not having direct submodule refs and links - though could be resolved in other ways.
- might need to review build and CI setup - although it would anyway be better and possible to have each package built separately rather than only in kohana/kohana
Stick with submodules, provide a sample composer.json and instructions on how to use it¶
- no real changes to existing project workflow, etc
- new users can't just grab the official application and run `composer install`
- limits options for adding/recommending other external packages in future
- doesn't move us forwards a great deal
Maintain separate composer and submodule based base apps¶
Probably the worst of both worlds - although because the composer version wouldn't need to always be updated to track module revisions it wouldn't take too much work to do...
#1 Updated by Sam Wilson about 1 year ago
I think using composer for modules is a great idea.
The extra learning of using composer over submodules is probably a small problem: I reckon there're probably more people struggling with submodules than with composer!
Does core fit into this as well? I mean, do you envisage the
system directory also be a composer dependency? It wouldn't be of type
kohana-module I guess...
#2 Updated by Andrew Coulton about 1 year ago
Yep, I'd envisage using composer for all of it (that's how we're starting to do it in our projects now). As of 3.3.1 core will have a composer.json but as a standard library package (so it would go in vendor/kohana/core).
I don't think that's a major issue, but it should be easy enough to add a
kohana-system package type to the composer/installers project if people really wanted to have it installed to system like it is at the moment.
#4 Updated by Maxim Kerstens 10 months ago
why not create a new repo called kohana/app similar to https://github.com/happyDemon/kohana-composer-bootstrap ?
Kohana would be installed (currently) as 'composer create-project happydemon/kohana-composer-bootstrap'
wouldn't there be a way to simply copy kohana/kohana without the system folder and the submodules during a build or something?
#6 Updated by Andrew Coulton 10 months ago
I think switching entirely to composer is emerging as the best solution. I don't know if we need a new repo, couldn't this (create the composer.json and delete the submodules) happen in eg the 3.4 branch in kohana/kohana? Although I guess a repo called kohana/sample-app or similar has the benefit of being clearer about what it is.
I think if we're doing that it would also make sense to submit a patch to composer/installers so that kohana-module packages are by default installed in vendor/ along with any other third-party dependencies. This would however break existing projects, unless there's a way in the installer to detect that and still use modules/. The alternative is to change the composer.json in the core kohana-module packages to be just normal libraries but that would again result in them being installed to a different path in existing projects (though only following an explicit upgrade by the user) and loses some semantic value and future potential. I could take a look at how hard it would be to update the kohana-module installer?
#7 Updated by Guillaume Poirier-Morency 2 months ago
Moving to composer is a nice idea. This will allow Kohana modules to define a wide range of dependencies.
Although, I think that modules designed specifically for Kohana should end in modules and external libraries in application/vendor. This makes a clear dinsinction between what gets autoloaded by the CFS and what gets loaded by composer. Technically, we add "vendor-dir": "application/vendor" in "config" in composer.json.
Then, only add a line after the modules loading in bootstrap.php
// Autoloading composer packages require Kohana::find_file('vendor', 'autoload');
This is pretty much what I do right now. This doesn't break anything and allow a full access to composer.