[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