Deprecate this project
soullivaneuh opened this issue · 28 comments
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
Dependents of this project are
- block
- page
- sandbox
If we go that way, we'll have to make them use symfony/cache instead.
Can we use symfony 3.1 cache without using the other symfony 3.1 componentents?
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:
- Implement both Symfony and Sonata cache on page-bundle
- Deprecate/Remove Sonata implement when SF version requirement will be higher than 3.1
- Deprecate this project
No because it will be a problem for people using Symfony fullstack.
How ?
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?
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.
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.
Glad to hear that, it's one less thing to worry about!
@greg0ire Could be problematic for Symfony integration of the component: http://symfony.com/blog/new-in-symfony-3-1-cache-component#symfony-integration
Can you elaborate?
Don't know yet, this why I said "Could". 😉
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.
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…
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.
Here is the commit that integrates the integration : symfony/framework-bundle@5e771c5
So two routes : either we use the integration and require framework bundle ~3.1 or we don't.
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 
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
Here is the commit that integrates the integration
Integraception?
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)
(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.
What I meant by that is "Just because it is not a bundle does not mean it cannot define services and configuration".
But I don't think Symfony defines services on the components.
But I don't think Symfony defines services on the component.
No it does not, see my UPDATE above
More than 2 year later, can we achieve this to have one bundle less to maintain? 🤔
👍 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
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.
More than 2 year later, can we achieve this to have one bundle less to maintain? 🤔
4 years later now ^^
I think we can after the PHP 8 upgrade, right?
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.