8000 Enable support for inline recipes (local recipe inside the package itself) by drupol · Pull Request #572 · symfony/flex · GitHub
[go: up one dir, main page]

Skip to content

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

Closed
wants to merge 3 commits into from
Closed

Enable support for inline recipes (local recipe inside the package itself) #572

wants to merge 3 commits into from

Conversation

drupol
Copy link
@drupol drupol commented Nov 19, 2019

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.

@pamil
Copy link
Contributor
pamil commented Nov 19, 2019

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 manifest.json in the same path as composer.json or be embedded into composer.json's extra configs. I think I prefer the latter (so that there are fewer config files and less chance for conflict with tools that use manifest.json file).

@bobdenotter
Copy link

For a project like Bolt, this feature would be very useful as well! 👍

@Pierstoval
Copy link
Contributor

I'm not sure that manifest.json is the right path.

Instead, I would rename the file to flex-recipe.json to be clearer about what it does. The manifest.json should stay in the recipes repository.

The reason is that there are some other tools that use the manifest.json convention in their settings, such as YunoHost.

@nicolas-grekas
Copy link
Member
nicolas-grekas commented Nov 20, 2019

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.

👎

@drupol
Copy link
Author
drupol commented Nov 20, 2019

@pamil

The only thing I'm not sure is whether Flex recipe should stay in manifest.json in the same path as composer.json or be embedded into composer.json's extra configs. I think I prefer the latter (so that there are fewer config files and less chance for conflict with tools that use manifest.json file).

@Pierstoval

I'm not sure that manifest.json is the right path.

I moved the content of it into composer.json['extra']['recipe'] to avoid the extra file in the repo.

@nicolas-grekas
Ok I understand, I just wanted to find a way to get rid of the extra work and waste of time that people have to do in order to publish a recipe. Couldn't we find a good compromise ?

I've updated the PR. Instead of relying on a file manifest.json at the root of the package, I'm relying on configuration found in composer.json['extra']['recipe'].

Sadly, as this seems to be a dead end, I'll leave this here and I won't update it from now on.

@nicolas-grekas
Copy link
Member

Ok I understand, I just wanted to find a way to get rid of the extra work and waste of time that people have to do in order to publish a recipe. Couldn't we find a good compromise ?

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!
I'm closing therefor.

@drupol
Copy link
Author
drupol commented Nov 20, 2019

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.

What I meant by "extra work and waste of time" is that, in order to publish a recipe:

  • Fork symfony/flex
  • Do a PR
  • Wait for the automatic validation
  • Fix if necessary
  • Wait for an owner to manually validate
  • Fix if necessary

Maybe the wording was not the best,true.
What I'm just trying to do is to reduce that amount of time to something as fast as publishing a package on Packagist for example.

Anyway, I'll find a better alternative.

@itsjavi
Copy link
itsjavi commented May 8, 2020

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.

tgalopin pushed a commit to tgalopin/flex that referenced this pull request Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0