Symfony 4 Compatibility

[yakobe]

Unfortunately this package is currently not compatible with Symfony 4.

The first issue that seems to appear is in the service definitions when running behat:

In YamlFileLoader.php line 798:
[Symfony\Component\DependencyInjection\Exception\InvalidArgumentException]

The configuration key "scope" is unsupported for definition "friendly.alice.fixtures.loader" in "/app/vendor/knplabs/friendly-contexts/src/Knp/FriendlyContexts/services/core.yml". Allowed configuration keys are "alias", "parent", "class", "shared", "synthetic", "lazy", "public", "abstract", "deprecated", "factory", "file", "arguments", "properties", "configurator", "calls", "tags", "decorates", "decoration_inner_name", "decoration_priority", "autowire", "autoconfigure", "bind".
The configuration key "scope" is unsupported for definition "friendly.alice.fixtures.loader" in "/app/vendor/knplabs/friendly-contexts/src/Knp/FriendlyContexts/services/core.yml". Allowed configuration keys are "alias", "parent", "class", "shared", "synthetic", "lazy", "public", "abstract", "deprecated", "factory", "file", "arguments", "properties", "configurator", "calls", "tags", "decorates", "decoration_inner_name", "decoration_priority", "autowire", "autoconfigure", "bind".

[Nek-]

There is many issues with Symfony 4 compatibility. This package is also not maintained ATM. For now you can refer to this: #247 (comment)

[yakobe]

Ah... ok.
When you say:

This package is also not maintained ATM.

Do you mean that the owners are not actively developing? Or does it also mean that submitted pull requests will not be reviewed and integrated (or will take a long time)?
If the repo is dead, perhaps it can be put up for adoption or retired officially? Otherwise it will block lots of people who use it from moving forward/updating while leading them into the idea that it might one day be updated.

[Nek-]

Do you mean that the owners are not actively developing?

Owners are not. I am the official maintainer of this library. (Many things impact the decision of not maintain this lib, including lack of time, not using this library on any of my projects and not good reaction of the team while forking another project on my company organization (for maintenance reasons))

Or does it also mean that submitted pull requests will not be reviewed and integrated (or will take a long time)?

Yes.

If the repo is dead, perhaps it can be put up for adoption or retired officially? Otherwise, it will block lots of people who use it from moving forward/updating while leading them into the idea that it might one day be updated.

I understand very well that. Also, I have some very interesting work staged for commit on my computer. I'm currently working on looking for somebody to help me with the maintenance of this project. But following problems are to consider:

• There's no stable version for this project. Which means we will not really able to release new things for people already using this project;
• New features and issues imply huge backward compatibility breaks

Things may move next week because I think this project is a nice one and I want to make it great again, and it looks like I'm not alone. If you're interested to see this project maintained again, please put a 👍 to motive us!

See you next week 😄.

[yakobe]

Sorry for the delay...
I understand the "lack of time" bit... it's always difficult to find time for open source. People just expect it to "be there and work".

From my side, I have use for this project and would love to see it maintained and improved.

I agree about your 2 problems above. Perhaps it is time to knock out version 1.0, give it a support branch and make master 2.0-dev. There will definitely be some backwards compatibility breaks because it depends on code that itself has moved on. Then some of the dependencies can be updated (e.g. for symfony 4 etc) and work can start towards it. It will be broken as hell at first, but at least it will be on the way. Then some other nice things could be considered like autowiring and allowing functionality to be disabled etc. My resources are unfortunately also limited 😕, but I am also willing to contribute in order to maintain and improve it.

[yakobe]

Hey @Nek-, did anything come out of the experiments discussed?

[pimolo]

@yakobe
A feature/1.x branch has been created in order to prepare the next big release, with a lot of BC breaks, so the master branch remains safe.
I think it's important because most of users use this branch currently (it is recommended in the doc unfortunately).

About compatibility with Symfony4:
I forgot about it when I wrote the roadmap, but it's the next big thing planned.
However, our dependency of nelmio/alice is not compatible with Symfony4, so we first need to update it and rewrite some internal things (fixtures creation and persistance).

It has been started with #249.

[yakobe]

Hi @Nek- and @pimolo. Is there likely to be any progress on this? Is there something that people can help with or should we consider alternative solutions?

[phpcdev]

@Nek-

I am currently upgrading my project to SF4 and all my behat steps created the last 3-4 years are strongly based of freindly-contexts. Is there a substitute or a way for me to not re-write hundreds of behat tests, still keep all the tests working and most importantly upgrade to sf4?

I understand this is not maintained anymore, but I can't be the only one with this dilema of droping all these behat tests that were created through out the years or re-write all of them and I hope there is something to do with it. You said you have no use for FriendlyContext in your own projects. Are you using another context package?

Thank you.

[gabrielmustiere]

News of the migration of the project to Sf4+ ? Ty

[yakobe]

I have the suspicion this project is abandoned. Perhaps one of the maintainers should mark it so that people are aware?

[gabrielmustiere]

@Nek- can you give us some details about this topic ?

[Nek-]

Sorry, I think this library can be considered as totally unmaintained. I'd like to focus the (little bit of) time I have on improving/fixing Behat itself the following weeks/months. :/

[yakobe]

Maybe it’s time to mark it so on packagist and on the readme? That will give people a heads up so they don’t get stuck like we are.

Also, perhaps someone can then create an maintained fork without fear of code divergence.

[alexislefebvre]

Maybe @FriendsOfBehat would be interested in adopting FriendlyContexts?

[Nek-]

If they are interested about (I don't think so) we can have a chat about it on symfony-devs slack.