search

api-platform / api-pack

A Symfony pack for API Platform
https://api-platform.com
MIT License
524 stars 32 forks source link

Don't restrict symfony/symfony packages #18

Closed nicolas-grekas closed 5 years ago

nicolas-grekas commented 5 years ago

Will allow "unpack" to replace the wildcard by what's in extra.symfony.require also. See https://github.com/symfony/flex/pull/443 This should be the best practice.

teohhanhui commented 5 years ago

I honestly do not understand why the * version constraint is a "best practice". And we don't have extra.symfony.require set here.

nicolas-grekas commented 5 years ago

Because that's a pack - and packs should not impose constraints on your deps.

nicolas-grekas commented 5 years ago

we don't have extra.symfony.require set here.

it's not "here", but in a flex-enabled app - which packs are built for.

teohhanhui commented 5 years ago

I still disagree. The extra.symfony.require in the app could be anything, and we cannot guarantee that things would actually work if we do not enforce our version constraints. (Of course, if the user does not use this pack, they might still install incompatible versions of the these optional dependencies.) These are the supported versions of Symfony components that we run our CI builds with.

teohhanhui commented 5 years ago

I think https://github.com/symfony/flex/pull/443 is brilliant, but it still does not sufficiently address the concern I've raised before. This PR made me realize that.

nicolas-grekas commented 5 years ago

That's not the responsibility of a pack (guarantee that things would actually work).

teohhanhui commented 5 years ago

This is how I think about it: a collection of dependencies that we've put together. And to me that also means the dependencies are in selected versions that work together.

But I see your point. (Especially because the type is symfony-pack, so I'd respect the semantics you've defined.)

dunglas commented 5 years ago

Thanks @nicolas-grekas