Skip to content
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

Symfony 6 support (without Flex dependency) #1402

Merged
merged 4 commits into from Mar 13, 2022

Conversation

loic425
Copy link
Contributor

@loic425 loic425 commented Dec 1, 2021

No description provided.

@ciaranmcnulty
Copy link
Member

These Psalm issues may have been resolved in the #1397 branch, and that commit could be cherry-picked

@loic425
Copy link
Contributor Author

loic425 commented Dec 2, 2021

@ciaranmcnulty I was looking the errors on the CI and I was wondering if you want to keep the support of php < 8.0.
Cause Symfony 6 has dropped support for PHP 7.4 and you override some Symfony console methods.

@webignition
Copy link
Contributor

Symfony 6 supports PHP >= 8.0.2, support for Symfony 6 requires dropping support for PHP < 8.0.2.

It's not really a question of whether you want to drop support for PHP < 8 but more of a realisation that this is, as far as I understand, dropping support for PHP < 8 is an unavoidable requirement.

In order to support Symfony 6, is there any other choice other than to drop support for PHP < 8?

@loic425
Copy link
Contributor Author

loic425 commented Dec 7, 2021

@webignition Yes I think this is ok with keeping PHP 7 support. I think I was wrong with the issue encountered.

@loic425
Copy link
Contributor Author

loic425 commented Dec 15, 2021

@ciaranmcnulty Could you approve running the CI build please?

@@ -31,7 +32,7 @@
*/
final class RunCommand extends Command
{
public function getApplication() : Application
public function getApplication() : ?BaseApplication
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method needs to return an instance of PhpSpec\Console\Application instead of Symfony\Component\Console\Application due to needing to subsequently call getContainer() which is a method of the former but not a method of the latter.

Is this change necessary? I'm not saying it isn't, just curious given the impact this change makes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried this out in my own attempt to get Symfony 6.0 working and I can't see the need for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I have to try again without these change...
But this is a different return typehint than the Symfony one and I'm not sure it can work.
Maybe just an assertion can be enough on phpspec code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Returning PhpSpec\Console\Application not only works but is necessary for the command to call PhpSpec\Console\Application::getContainer().

You are correct in saying that the return type is different. An instance of PhpSpec\Console\Application is acceptable to return here as it is a child type of (i.e. extends) Symfony\Component\Console\Application. Technically speaking, this is a covariant return type and support was introduced in PHP 7.4.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you're right. But "we" have to drop support for PHP 7.3 then.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I think we can drop support for Symfony 3 too... It is not maintained anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ciaranmcnulty Are you ok to drop both PHP 7.3 and Symfony 3 support?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PHP 7.3 concern is a valid point that I completely failed to consider and that does complicate things somewhat. But with PHP 7.3 now being EOL, I don't think it's fully unwise to consider dropping support.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should keep this returning Application, then do a runtime assertion in the code that it's a BaseApplication we got back

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can keep the existing code code, cause on PHP lower than 8.0 we have not symfony 6 downloaded so this still works with no return type on symfony lower than 6.

@loic425
Copy link
Contributor Author

loic425 commented Dec 22, 2021

CI should be fixed before with that PR and Psalm error too

@shouze
Copy link

shouze commented Jan 30, 2022

@webignition @ciaranmcnulty do you think guys this PR can get merged soon, I can help if any other blocker 👼

@webignition
Copy link
Contributor

@shouze There's nothing in particular that I can do to help speed things along other than suggest what might need to happen next.

Which is, in the following order:

  1. merge Run psalm against PHP version that is being used by workflow #1408 to prevent psalm from trying to check PHP 8.x code against PHP 7.x (@ciaranmcnulty)
  2. rebase this branch against master (@loic425)
  3. kick off the build checks for this PR (@ciaranmcnulty)
  4. address any issues if the checks for this PR don't pass

@ciaranmcnulty Does this seem like a good approach?

@loic425
Copy link
Contributor Author

loic425 commented Jan 31, 2022

@webignition I would add the PHP 8.1 support PR between first and second steps

@shouze shouze mentioned this pull request Feb 9, 2022
@loic425
Copy link
Contributor Author

loic425 commented Mar 7, 2022

@ciaranmcnulty I will work on this PR this week now you merged the other needed PRs. Thx a lot

@loic425
Copy link
Contributor Author

loic425 commented Mar 8, 2022

@ciaranmcnulty Do you really want to maintain PHP 7.3 support?
Please look at this thread #1402 (comment).

Capture d’écran 2022-03-08 à 08 48 00

But if we keep PHP 7.3 support, we have to change this typehint and adding an extra check on the method.

@loic425
Copy link
Contributor Author

loic425 commented Mar 9, 2022

@ciaranmcnulty Could you run the CI on this one please?
Let's move forward an bring that support to the whole Symfony community.

@ciaranmcnulty
Copy link
Member

I don't mind dropping 7.3 support, it'll just mean a new major (only because that's the convention we established) - it should drop unmaintained Symfony too

@loic425
Copy link
Contributor Author

loic425 commented Mar 9, 2022

I don't mind dropping 7.3 support, it'll just mean a new major (only because that's the convention we established) - it should drop unmaintained Symfony too

Great, in this current PR? CI is green for other PHP versions.

@ciaranmcnulty
Copy link
Member

I've updated the next branch to reflect the minimum PHP and Symfony versions we'll support in 8.0.0.

Can you target this PR against that branch please?

@ciaranmcnulty ciaranmcnulty changed the base branch from main to next March 11, 2022 21:24
@ciaranmcnulty ciaranmcnulty changed the base branch from next to main March 12, 2022 10:31
@ciaranmcnulty
Copy link
Member

ciaranmcnulty commented Mar 12, 2022

I got another chance to think about this; I think we should support PHP 7.3. The next major will be 8.0+ and that will leave Symfony users who want to use SF 6.0 but are stuck on PHP 7.4 without a version to use.

(commented inline in code how we can support 7.3)

@loic425
Copy link
Contributor Author

loic425 commented Mar 13, 2022

I got another chance to think about this; I think we should support PHP 7.3. The next major will be 8.0+ and that will leave Symfony users who want to use SF 6.0 but are stuck on PHP 7.4 without a version to use.

(commented inline in code how we can support 7.3)

Do you have an Idea to solve the last error. It seems to need some investigation but this is not related to this PR imho.

@ciaranmcnulty
Copy link
Member

Do you have an Idea to solve the last error. It seems to need some investigation but this is not related to this PR imho.

It's fixed on main, please rebase

@loic425
Copy link
Contributor Author

loic425 commented Mar 13, 2022

It's fixed on main, please rebase

done

@ciaranmcnulty ciaranmcnulty merged commit 717b82d into phpspec:main Mar 13, 2022
@ciaranmcnulty
Copy link
Member

Thank you, I plan to do a release of PhpSpec 7 and then 8 (from next branch)

@loic425 loic425 deleted the symfony-6-support branch March 14, 2022 07:41
@loic425
Copy link
Contributor Author

loic425 commented Mar 14, 2022

Thank you too @ciaranmcnulty 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants