New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] [Kernel] Add the Kernel component #29275

Open
alquerci opened this Issue Nov 21, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@alquerci
Contributor

alquerci commented Nov 21, 2018

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? yes on version 5.1
Fixed tickets #27479
License MIT

Goal

Be able to provide a very tiny application with the power of the DIC.

Description

Add ability to use the Dependency Injection factory without HTTP dependencies.

Currently the HttpKernel component depends on a lot of packages. However, as soon as we remove all HTTP features dependencies becomes fewer:

  • symfony/config
  • symfony/dependency-injection.

One solution is to create the symfony/kernel to ease the decoupling.

For history: a similar work has been done for the security component.

Context

Symfony took the path to be tiny and fast. However, CLI applications still required the HttpKernel and all related HTTP dependencies that is completely overkill. And this only to have the ability to build and instantiate the service container.

There are also other projects that wants to use or initiate the migration to Symfony. Where migrating the business logic to use the dependency injection component is one of the first action to do.

What will this component contain?

All not HTTP related features of the HttpKernel.

src/Symfony/Component/Kernel/
├── Bundle
│   ├── BundleInterface.php
│   └── Bundle.php
├── CacheClearer
│   ├── CacheClearerInterface.php
│   ├── ChainCacheClearer.php
│   └── Psr6CacheClearer.php
├── CacheWarmer
│   ├── CacheWarmerAggregate.php
│   ├── CacheWarmerInterface.php
│   ├── CacheWarmer.php
│   └── WarmableInterface.php
├── Config
│   └── FileLocator.php
├── DependencyInjection
│   ├── AddAnnotatedClassesToCachePass.php
│   ├── ConfigurableExtension.php
│   ├── Extension.php
│   ├── LoggerPass.php
│   ├── MergeExtensionConfigurationPass.php
│   ├── ResettableServicePass.php
│   └── ServicesResetter.php
├── EventListener
│   └── DumpListener.php
├── KernelInterface.php
├── Kernel.php
├── Log
│   └── Logger.php
└── RebootableInterface.php

Road-map (draft)

  • Extract the kernel from the HTTP one
    • Provides a back compatibility layer for Symfony4.
    • The symfony/http-kernel requires and extends the new symfony/kernel component.
  • Extract, migrate, refactor the documentation
  • Trigger deprecation on version 5.1
  • Remove BC layer on version 6.0

Next (out of topic)

  • Touch the FrameworkBundle to follow the same path.

Migration path (draft)

Required

To migrate to Symfony5: rename the namespace for classes moved to the new component.

-namespace Symfony\Component\HttpKernel\*;
+namespace Symfony\Component\Kernel\*;

Optional

  • For bundles that do not use HTTP functionality, it will be up to the maintainer to remove the HTTP dependency because the migration will not be required.

Resources

cc @stof

@stof

This comment has been minimized.

Member

stof commented Nov 21, 2018

your migration path is incomplete. What is the migration path for bundles needing to support multiple versions of Symfony (and without getting a deprecation warning, so that they don't get bug reports from all their user requiring them to migrate in a way dropping support for the old version) ?

@stof

This comment has been minimized.

Member

stof commented Nov 21, 2018

And this also miss other parts of the migration. Currently, KernelInterface extends httpKernelInterface. How does the HTTP handling looks like once the kernel is not an HttpKernel anymore ?

@PabloKowalczyk

This comment has been minimized.

Contributor

PabloKowalczyk commented Nov 21, 2018

Add ability to use the Dependency Injection factory outside of HTTP context.

Did you mean "Add ability to use the Dependency Injection outside of HTTP context." (without the factory)?

Why symfony/config is a dependency?

BTW i like this RFC very much, thanks @alquerci ! 🎉

@alquerci

This comment has been minimized.

Contributor

alquerci commented Nov 21, 2018

@stof

What is the migration path for bundles needing to support multiple versions of Symfony?

Do you mean for bundles that wants to support multiple major versions of Symfony. However, even for minor versions this is a good question. So the road to find a solution is to test it. Can you provide a bundle for which this case will happen.

Deprecation are caught and triggered by the debug component even for third party libraries? For this case that is not the first deprecation on the Symfony life. But this one have a different impact, is it?

This is for sure something to resolve before going forward.

How does the HTTP handling looks like once the kernel is not an HttpKernel anymore ?

HttpKernel\Kernel will extends Kernel\Kernel to provide exactly same features as before.
You can see an example there.


@PabloKowalczyk

Did you mean "Add ability to use the Dependency Injection outside of HTTP context." (without the factory)?

Symfony already provides the ability to use the DIC without any factory. The main scope of this issue is about the DIC factory.

Why symfony/config is a dependency?

To use the ConfigCache and create the config loader as the DIC required a configuration.

@stof

This comment has been minimized.

Member

stof commented Nov 22, 2018

Do you mean for bundles that wants to support multiple major versions of Symfony. However, even for minor versions this is a good question. So the road to find a solution is to test it. Can you provide a bundle for which this case will happen.

For the ecosystem, we need to allow supporting LTS + next major version at the same time (otherwise bundles will drop support for the LTS, making it useless) and also multiple minor versions at the same time.
And whatever version this changes gets integrated in, some older versions will still be maintained at that time, so it means that bundles will need to be able to support both versions.

For this case that is not the first deprecation on the Symfony life.

It is indeed not the first one. But we also already rejected some changes in the past because the migration path for the ecosystem was considered too high compared to the benefit. And recently (in #29218), we reverted a deprecation, delaying it to the future, for a similar reason. Considering the cost of the migration, both for projects and for the open-source ecosystem is a necessary part of the decision about deprecating something.

@alquerci

This comment has been minimized.

Contributor

alquerci commented Nov 22, 2018

Then if I correctly understood: On version 4.3 adding the component with the BC layer then the deprecation will be triggered on version 5.1 and the BC layer removed for version 6.0.

EDIT:
Road-map updated.

--- before	2018-11-22 20:55:35.352978864 +0100
+++ after	2018-11-22 20:55:40.337007783 +0100
@@ -5,3 +5,5 @@
     * Provides a back compatibility layer for Symfony4.
     * The `symfony/http-kernel` requires and extends the new `symfony/kernel` component.
 - [ ] Extract, migrate, refactor the documentation
+- [ ] Trigger deprecation on version 5.1
+- [ ] Remove BC layer on version 6.0
@Pierstoval

This comment has been minimized.

Contributor

Pierstoval commented Nov 23, 2018

Then if I correctly understood: On version 4.3 adding the component with the BC layer then the deprecation will be triggered on version 5.1 and the BC layer removed for version 6.0.

No, this means adding the component in 4.3 must not break anything, it can deprecate old behaviors, and the deprecated code will be removed/modified for 5.0.

With your roadmap, waiting for 6.0 to remove BC layer means that you would have to wait until 2021 for the feature to come... A bit too long, maybe :)

However, with a better migration path (like adding the component for 4.3 and make it not break anything), you might be able to mark the component as experimental if necessary, so the existing code would still work, but if the new component is required, it's used, and might introduce breaks in next minor (this is mostly valid if the component is released in 4.3, that wouldn't be the case for 4.4 because there is no next minor in this case).

To me, if the component is accepted by the core team, it needs to be released in 4.3 or 4.4, and old code must be removed in 5.0, in one year 😄

I hope I don't miss anything about the release process 😕

@alquerci

This comment has been minimized.

Contributor

alquerci commented Nov 23, 2018

Hello @Pierstoval

With your roadmap, waiting for 6.0 to remove BC layer means that you would have to wait until 2021 for the feature to come... A bit too long, maybe :)

The feature is to extract the DIC factory from the HttpHernel. Then as soon as the new component is released the feature going live too.

What did you expect?

adding the component for 4.3 and make it not break anything

That's already the plan as you can see on Resources section.

Can you share what will be broken even with the BC layer?

To me, if the component is accepted by the core team, it needs to be released in 4.3 or 4.4, and old code must be removed in 5.0, in one year

I had thought the same but @stof is right about bundles, see #29275 (comment) .


I am ready to find a solution for each blocker points.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment