Deprecate this project

[soullivaneuh]

Symfony 3.1 now has it own cache component: http://symfony.com/blog/new-in-symfony-3-1-cache-component

Maybe it will be better to deprecate this project and make cache-bundle relying on the Symfony component?

cc @rande @sonata-project/contributors

[greg0ire]

Dependents of this project are

• block
• page
• sandbox

If we go that way, we'll have to make them use symfony/cache instead.

[core23]

Can we use symfony 3.1 cache without using the other symfony 3.1 componentents?

[greg0ire]

Looks like we can

[soullivaneuh]

Can we use symfony 3.1 cache without using the other symfony 3.1 componentents?

No because it will be a problem for people using Symfony fullstack.

What should be done ATM:

1. Implement both Symfony and Sonata cache on page-bundle
2. Deprecate/Remove Sonata implement when SF version requirement will be higher than 3.1
3. Deprecate this project

[greg0ire]

No because it will be a problem for people using Symfony fullstack.

How ?

[soullivaneuh]

Symfony FS replaces the cache component. It will be a conflict if we require symfony/symfony 2.8.* and symfony/cache ^3.1.

Am I wrong?

[greg0ire]

Symfony FS provides the cache component

I don't get this sentence, and I don't see any mention to symfony in the conflict section of symfony/cache. I have a 2.8 project, just let me try, we'll know.

[soullivaneuh]

In fact, you are right.

I did a composer require 'symfony/symfony:2.8.*' 'symfony/cache:^3.1' and it works.

Certainly because symfony/cache does not exist on symfony/symfony 2.8.

[greg0ire]

Glad to hear that, it's one less thing to worry about!

[soullivaneuh]

@greg0ire Could be problematic for Symfony integration of the component: http://symfony.com/blog/new-in-symfony-3-1-cache-component#symfony-integration

[greg0ire]

Can you elaborate?

[soullivaneuh]

Don't know yet, this why I said "Could". :wink:

The cache is a component, not a bundle, but the documentation clearly indicate that you cam use services like: cache.adapter.redis.

We have to investigate where this is defined and if this part can be installed with symfony/symfony 2.8 or 3.0.

[greg0ire]

We have to investigate where this is defined and if this part can be installed with symfony/symfony 2.8 or 3.0.

It's not a bundle, but it is not a library either, and as such, can define configuration and services, in a very classical way I guess. Nothing fancy. Let me have a look.

UPDATE: at first look, it seems you're right, there is no DependencyInjection namespace in the Component…

[greg0ire]

Oh but the configuration is defined under framework, so that's where it should be defined, but not until 3.1 I think. So there is indeed a problem.

[greg0ire]

Here is the commit that integrates the integration : https://github.com/symfony/framework-bundle/commit/5e771c5b46bbd62d574a8ac819bdd0a83c112b1e

So two routes : either we use the integration and require framework bundle ~3.1 or we don't.

[soullivaneuh]

It's not a bundle, but it is not a library either

It is. A Symfony component is a library. It can be used alone.

Plus: https://github.com/symfony/cache/blob/v3.1.1/composer.json#L3 :trollface:

Another issue (for now): This library is compatible with PHP 5.5+ only: https://github.com/symfony/cache/blob/v3.1.1/composer.json#L22

[soullivaneuh]

Here is the commit that integrates the integration

Integraception? :trollface:

[greg0ire]

It is. A Symfony component is a library. It can be used alone.

A bundle is a library too, you troll! You know what I meant ;) (if you don't, I meant "it's not just a library")

Another issue (for now): This library is compatible with PHP 5.5+ only: https://github.com/symfony/cache/blob/v3.1.1/composer.json#L22

Then maybe go solution 1 (use the integration)

[soullivaneuh]

(if you don't, I meant "it's not just a library")

Outside the troll, no I don't can you please elaborate the "not just"?

Then maybe go solution 1 (use the integration)

I don't see the problem to propose both for a while and deprecated our after that.

Anyway, we have to look at the difference between our cache library and the Symfony one too.

[greg0ire]

What I meant by that is "Just because it is not a bundle does not mean it cannot define services and configuration".

[soullivaneuh]

But I don't think Symfony defines services on the components.

[greg0ire]

But I don't think Symfony defines services on the component.

No it does not, see my UPDATE above

[OskarStark]

More than 2 year later, can we achieve this to have one bundle less to maintain? 🤔

[core23]

👍 There are only 16 projects, that depend on this https://packagist.org/packages/sonata-project/cache/dependents

And 31 for the bundle https://packagist.org/packages/sonata-project/cache-bundle/dependents

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[VincentLanglet]

More than 2 year later, can we achieve this to have one bundle less to maintain? 🤔

4 years later now ^^

[OskarStark]

I think we can after the PHP 8 upgrade, right?

[VincentLanglet]

I think we can after the PHP 8 upgrade, right?

I don't think it's related to the PHP8 upgrade.

We "just" have to drop the cache/cache-bundle dependency in

• https://packagist.org/packages/sonata-project/dashboard-bundle
• https://packagist.org/packages/sonata-project/page-bundle
• https://packagist.org/packages/sonata-project/block-bundle
• https://github.com/sonata-project/sandbox/blob/master/composer.json

I never used Symfony Cache, might be good if some else (@sonata-project/contributors) wanted to do it.