PoC: Load manifest.json from local bundle

[icanhazstring]

This is a PoC for #745.

This will add the ability to receive the manifest.json for symfony/flex from an installed symfony-bundle.
I did this to be able to provide a recipe for a proprietary bundle without the need to setup a recipe server.

Each bundle should have its own (already versioned) manifest.json inside a <package>/recipe/ folder.
This should resemble the same specs as for github.com/symfony/recipe.

To reproduce that this is working:

1. Setup a symfony application (symfony new flex-test)

2. Create a small local symfony bundle with this composer.json

   {
     "name": "flex-test/symfony-bundle",
     "type": "symfony-bundle",
     "require": {
       "php": "^8.0",
     }
   }
   

   And this manifest.json in <package-path>/recipe/manifest.json

   {
     "env": {
       "SYMFONY_TEMPLATE": "magic"
     }
   }
   

3. Add repositories inside your flex-test application composer.json to receive the bundles and the poc

   {
     "repositories": [
       {
         "type": "path",
         "url": "<path-to-bundle>/symfony-bundle"
       },
       {
         "type": "vcs",
         "url": "https://github.com/icanhazstring/flex"
       }
     ]
   }
   

4. Require symfony/flex:dev-main and flex-test/symfony-bundle:dev-main

5. The .env file should have the following content:

   ###> flex-test/symfony-bundle ###
   SYMFONY_TEMPLATE=magic
   ###< flex-test/symfony-bundle ###
   

---

Feel free to give some feedback for this.

[icanhazstring]

@fabpot maybe you have some feedback if we could implement this and maybe how to improve it.

This current implementation is obviously not perfect and "just a hack" to get the idea how this could work.

[icanhazstring]

Another Idea I had:

We could provide a possibility that one could provide some kind of ManifestProvider.
For example:

The default provide would be SymfonyRecipeProvider, this behaves like the current implementation and looks for recipes on https://github.com/symfony/recipes.

Another way around would be to register other providers in some form of configuration: .flex.yaml.

providers:
    - Company\ProprietaryRecipeServerProvider
    - App\Flex\LocalRecipeProvider

This list of providers will be iterated by the flex implementation and will in priority order (SymfonyRecipeProvider should be last in line) in order to fetch some manifest. If one is found the iteration stops. This would give the user an even more flexible implementation for example a company can create another proprietary composer package having their recipes on a local server rather than in the packages themself.

[nicolas-grekas]

Thanks for the PR.

The separate repo is on purpose: recipes are installation instructions that belong to a distribution (as in "Linux distribution"), not to the source package.

We could decide one day that Symfony is a standard enough distribution, but we're not ready yet. Eg this would prevent running checks, or this would prevent mass changes that we might want to do at once on all recipes, or that would prevent compiling yaml files into php the day we'll want to provide a "php-dsl" flavor of recipes.

I didn't think about it: maybe there is a way to put files in a source package and auto-submit a PR to keep it in sync with the recipes repository? I think it could be worth investigating instead.

About the need for private repos, this should be unlocked by #803

Closing therefor.

[icanhazstring]

Thanks for the update. Not in favor of my idea, but a valid and reasonable decision 👍

[MichaelBrauner]

So from a bundle builder's point of view, that would be a killer feature.

I think that just by writing a symfony bundle and not a simple PHP package, you commit yourself to a certain extent. Some bundles have a PHP library included and use it as a symfony bundle. Is this not enough?

When I install a bundle, I'm asked anyway if I want to run the associated recipe or not. With official recipes, this is even done without my intervention. So what difference does it make if the recipe is outside or inside the bundle repository?

How many bundles are there that may want to have their code used in different ways that require multiple external recipes?

Is it wise to withhold such an absolute killer feature that would obviously be easy to implement?

[icanhazstring]

With flex now being able to use another source for recipes, I would recon one could write it so, that is looks inside the package and then on a server?

Maybe another PoC would be feasible now.