Allow packs to embed their recipe #924
Conversation
|
Why allowing to install a recipes from a pack but not from a regular composer package (a lib for instance)? |
|
So if I then write a blog bundle, I would need an external pack repository instead of an external bundle repository? Have I understood that correctly? |
|
@MichaelBrauner this is already the situation yes. And while the "symfony distribution" argument doesn't stand for bundles I agree, there are other reasons to keep the central repo I mentioned there. Eg the validation of recipes, the review steps to ensure a consistent ecosystem, and more recently the |
Are the areas of application not already limited by the range of functions flex offers? As an example. I don't see any use-case for me, but someone would maybe just copy some Entities and FormTypes. When this is a good idea in a specific recurring scenario. Why should it be restricted? When I use composer packs now - I can do that without control and restriction, isn't it?
Yes, that's a good one 👍 !
I can only agree with that. What would offer more to the Symfony ecosystem and make it even more attractive? And what does the community want? Are there many developers who would like to keep Flex as it is now - or are there mostly developers who would like it to be more direct and simple - without decoupled Git repositories? |
|
On second thought and after talking with a few others, we don't need this for the scaffolding feature we'd like to work on. |
|
Ok. Thank you for your wonderful work . |
By making packs able to embed their recipe, we enable using them for scaffolding feature-full applications.
Note that such local recipes cannot be managed with any
composer recipes:*command, and this is a feature :)At the community scale, this might allow ppl to work around the central repository of recipes if authors maintain a pack next to their main lib. But this looks fair to me, especially with the noted limitation of packs' recipes. We do want to allow ppl to create scaffolds, even if it's for one lib.
(Note also that since #923, recipes bound to packs via the central repository are now update-able, so we don't need the
*-metarepos anymore.)On a technical level, this works as is:
composer require the/packinstalls the pack and all its deps using the regular composer flow,the/packinto the rootcomposer.json,vendor/the/pack/directory into a recipe and installs it,the/pack, thus removingvendor/the/pack/🪄
One last note: embedded recipes escape the CI we have in place on the central repo. We might want to provide a callable GHA to make it easier for authors to verify them. This GHA could also check conflicts between the central repo and packs' recipes (overridden files typically), to ease propagate changes from the central repo to the overriding packs.