[TYPO3-dev] composer install typo3/cms

Fabien Udriot fabien.udriot at typo3.org
Thu Feb 6 11:56:33 CET 2014


> Ok, sounds good - additionaly if you don't want this additional user, 
> you could trigger the update manually. Maybe it might be a good idea 
> to name this user typo3-gerrit to not confuse extension authors?

Could be, but then it is more logic to add in the Gerrit Hook because we 
would have to detect whether it is "typo3" or "typo3-gerrit" the 
maintainer.

> So, you'd submit the sysexts to packagist separately? I thought, it 
> would be fine if the typo3/cms package would just provide them by the 
> provide [1] key in composer.json (as the lightwerk guys did in their 
> repository). Thus they would be published and coupled to the core 
> also.

If we are not forced to submit the sysexts to Packagist separately, it 
is better of course. I considered this approach as required if we wanted 
to be modular by deploying a custom Core with Composer. My use case 
would be to only download certain Core Packages and build up a Core as 
light as possible. It must not be forgotten that even a Core Package is 
not activated it takes some processing time (not that much but still). 
And on a more conceptual aspect, I don't want to see code that I don't 
need.

I noticed the "provide" key you mentioned in the composer.lock when 
installing the demo http://composer.lightwerk.com/composer.json. Still 
in the discovering phase of the Composer universe!

> Fixing all tags in the main repo would be great in terms of 
> straightness but I think for the composer venture I would go with 
> Philipp's suggestion.

Of course, the composer venture starts as of 6.2. No renaming of old 
tags.

>
> Our roadmap provides for a basic 1/2/3-install by the composer 
> installer as well as an extension installer for composer that would 
> delegate to the TYPO3 CLI extension installer.

All sounds good.

Some general thoughts: I am still thinking what is the boundary with the 
Extension Manager which is (was?) the usually way of managing 
extensions. It looks new doors are opening. Composer for sure brings 
flexibility because it can connect packages from various places. 
Activation of a Package still remains the task of the CMS. It will be 
done by CLI via the install command:

$> ./typo3/cli_dispatch.phpsh extbase extension:install foo

This being said the Extension Manager has the big advantage of having a 
GUI for people who don't want to hear from command line even if they are 
dead simple.

> But composer doesn't know the concept of de/activating packages - so I 
> think it's still up to TYPO3 to organise, which packages of the 
> "composer installed" are "TYPO3 activated".

... this would be triggered by a [Composer 
event](https://getcomposer.org/doc/articles/scripts.md#event-names).

>> It goes into the same direction, does it?
>> https://github.com/lightwerk/typo3cms-installers
>
> Yes, but some steps further (those installers actually just download 
> the TYPO3 / extension sources).

Cool to have people experimenting. And good if they share their 
findings.

Have a nice day,

Fabien


More information about the TYPO3-dev mailing list