[FLOW3-general] Deactivate packages in certain contexts

Robert Lemke robert at typo3.org
Mon Oct 29 10:53:20 CET 2012


Hi Bastian,

On 29.10.2012, at 10:39, Bastian Waidelich <bastian at typo3.org> wrote:

>> This generally makes sense, absolutely. We have to think about what
>> possible uses cases might follow. One would be a different version of a
>> library in a certain context - change packagePath and you're set - as
>> discussed looong ago.
> 
> Right. Also we need to check if disabled packages are *really* not accessible (does the autoloader load classes from disabled packages?).
> But those issues are the same as we currently have with "globally" disabled packages.

As I briefly mentioned, that is my biggest concern: If you can enable / disable packages
per context, they must be truly, fully, enabled or disabled – that is, classes must not be
loadable by the class loader.

As far as I remember, that is the case already, but I don't know about the implications of
PSR-0 / non-Flow packages now introduced with composer.

Another implication is that dependencies defined in the Composer manifests of the packages
must be respected.

So, if you can solve that, I'd favor your suggestion with PackageStates.php and the array
syntax.

The biggest con, from my point of view is that it can get quite confusing to figure out which
package is active when. I suggest that the package:list command for example starts displaying
a little matrix with [X] [ ] as soon as one package is configured to be active in a certain context only.

>> I see another option in addition to your solution of adding the context
>> inside PackageStates.php - and that would be to handle it like other
>> settings - per context-directory files. Those could either be used
>> instead of the global one or merged like Settings.yaml (the former is
>> technically easier!).
> 
> Do you mean something like a Package.yaml?


no, I think he means:

PackageStates.php
Development/
	PackageStates.php
Production/
	PackageStates.php

But I don't like that a lot as it's PHP.

Yaml is not an option because there's no Yaml parser loaded at the point we need the 
information.

Cheers,
Robert

-- 
Robert Lemke
Lead Developer TYPO3 Neos and TYPO3 Flow
Co-Founder TYPO3 Association

Blog: robertlemke.com/blog
Get involved: typo3.org – flow.typo3.org – neos.typo3.org







More information about the FLOW3-general mailing list