-
-
Notifications
You must be signed in to change notification settings - Fork 195
Enable support for inline recipes (local recipe inside the package itself) #572
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
Conversation
This is an idea that we thought about in Sylius a lot when we started to craft recipes for Symfony Flex. In my opinion, code, docs and recipes should be a part of the same repository, so that they can stay synchronised and be cross-referenced easily. This way I could create a test Symfony application in my repo and make sure my recipes are correct within single CI build. Another common case for me is to provide a new feature flag in bundle's configuration to keep backwards compatibility but allow for the usage of new behaviour. It looks like the following: my_bundle:
new_behaviour: true # defaults to false I want existing packages to use the old behaviour, but any new installation should get the new one. Currently, it requires two PRs, one to my bundle repo and one to recipes-contrib repo (which also require my library to be tagged). The only thing I'm not sure is whether Flex recipe should stay in |
For a project like Bolt, this feature would be very useful as well! 👍 |
I'm not sure that Instead, I would rename the file to The reason is that there are some other tools that use the |
Please don't spend too much time on this, it has been rejected in the past and will be again: a recipe is an opinionated way to use a library. The way some code is used should be totally decoupled from the code itself. That's two completely decoupled domains and they should remain decoupled technically too. Linux distributions do it right if you want a comparison: library authors ship code but don't care about packaging it for specific distributions - then each distribution has a dedicated configuration per package that fits their philosophy. That's the proper separation of concerns. Same here. 👎 |
I moved the content of it into @nicolas-grekas I've updated the PR. Instead of relying on a file Sadly, as this seems to be a dead end, I'll leave this here and I won't update it from now on. |
Note that I'm not specifically aware of any facts supporting the narrative about "extra work and waste of time". Most of the discussions around the topic are quite constructed to my understanding. Anyway, thank you for trying! |
What I meant by "extra work and waste of time" is that, in order to publish a recipe:
Maybe the wording was not the best,true. Anyway, I'll find a better alternative. |
This functionality (inline recipes) can be probably implemented via composer hooks, at the cost of reinventing the wheel, kind of. I still don't get why flex is so opinionated and you can't give the choice to the developers to use the centralised recipe server or not. It's like if someone now says that all composer.json scripts will have to live in a centralised service and will not be allowed to be in the repositories themselves anymore. I hope you are more open minded about this at some point, because it seems the community is trying to push for this, or for an alternative. |
This PR:
This PR enable support for recipe inside a package.
Basically when you install a package that doesn't have an official recipe and if the
composer.json
has ['extra']['recipe'], then that property will be used as recipe.I personally really would like to see this in because I don't like so much the actual process of submitting new recipes and based on comments from #206, I think it would be a nice feature.