-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Add Kernel::getProjectDir() #22315
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
Add Kernel::getProjectDir() #22315
Conversation
And it's a bit related (but not so much too...), but having the path to the console binary (if there's one) could be useful too |
Finally! \o/ |
@@ -4,6 +4,8 @@ CHANGELOG | |||
3.3.0 | |||
----- | |||
|
|||
* Added `kernel.project_dir` and `Kernel::getProjectDir()` | |||
* Deprecated `kernel.root_dir` and `Kernel::getRootDir()` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not happening right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Virtually at least :) We cannot really display a deprecation as it's used everywhere. But, I want to get rid of it in Symfony Flex, so that in 4, we can really deprecate root_dir
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it should have a @deprecated
but not a trigger_error()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well.. deprecation !== crashing :) then again migrating it is a burden.. so i see we care a bit more here.
Adding @deprecated
sounds like a good idea 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
This PR was merged into the 3.3-dev branch. Discussion ---------- Add Kernel::getProjectDir() | Q | A | ------------- | --- | Branch? | master | Bug fix? | yes/no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | not yet `Kernel::getRootDir()` is misleading. It returns the path where `AppKernel.php` is stored, which is `app/` in Symfony 2/3, but `src/` in Symfony 4. But most of the time, we are using `getRootDir()` to get the project root dir, so `%kernel.root_dir%/../` is a common idiom. Changing the value of `getRootDir()` would be a hard BC break, so I propose to create a new method, `getProjectDir()` to "replace" `getRootDir()` gradually. Commits ------- 1f680cc added Kernel::getProjectDir()
Why not introduce a getKernelDir method as well? It would allow deprecating getRootDir via phpDoc today, and for real in 4.0. PhpDoc deprecations are only respected by IDEs and code checkers so that should ease transition. |
This new parameter and method will appear in Symfony 3.3 as per symfony/symfony#22315 We will remove it then.
Docs issue created and PR description updated - let's make sure we keep track of everything :) (docs team has a lot of catching up to do, but I hope we'll at least have a complete issue list to work from!) |
This PR was merged into the 3.3-dev branch. Discussion ---------- [HttpKernel] sync upgrade files | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #22315 | License | MIT | Doc PR | Commits ------- a90e461 sync upgrade files
*/ | ||
public function getProjectDir() | ||
{ | ||
if (null === $this->projectDir) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This implementation is really strange. It basically assigns the variable twice. Once in the method and once in the constructor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tobion the method itself can be overwritten to change the logic (for instance for people wanting to avoid issues with open base dir). But the Kernel still wants to ensure its private property stores the right thing.
And then, the default implementation relies on the property internally to avoid doing the filesystem traversal multiple times
@@ -59,6 +59,8 @@ | |||
protected $startTime; | |||
protected $loadClassCache; | |||
|
|||
private $projectDir; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this is private
and not protected
like $rootDir
. I need to override this in my kernel and can't really do at runtime…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the extension point is the public method, not the property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the issue is that the property is set in __construct
and later used by getKernelParameters
. My kernel does not know the path at construct time, so I would need to override multiple methods for no reason…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making things protected means we then have to ensure backward compatibility on the access to the property. This is a strong commitment. So we never replace private with protected without a strong use case for it. And if you have one, please open a dedicated issue to discuss it instead of doing it on the merged PR (people are generally looking at opened discussion only when catching up)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #22727
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #22728 for alternative
This PR was merged into the 3.3 branch. Discussion ---------- use getProjectDir() when possible | Q | A | ------------- | --- | Branch? | 3.3 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | continues #22315 | License | MIT | Doc PR | Commits ------- a8e298a use getProjectDir() when possible
Kernel::getRootDir()
is misleading. It returns the path whereAppKernel.php
is stored, which isapp/
in Symfony 2/3, butsrc/
in Symfony 4. But most of the time, we are usinggetRootDir()
to get the project root dir, so%kernel.root_dir%/../
is a common idiom.Changing the value of
getRootDir()
would be a hard BC break, so I propose to create a new method,getProjectDir()
to "replace"getRootDir()
gradually.