[Proposal] Allow to extend Flex #173
Comments
|
What kind of extension point would you need ? Just adding a way to replace everything only opens the door for weird breakages (especially given that we are still making changes to Flex). Regarding |
|
For configurations specific to a project, I don't see the need to customize recipes for that: recipes will give you the initial configuration of the package in your project. But then, you are free to update the configuration as you want. These files become part of your project. And regarding private repositories, the best way to support them would probably be to support multiple repositories in the plugin (currently, the repository is configurable but it replaces the existing one). |
|
I just need to be able to override For |
What's your use case, exactly? Besides private recipes, what kind of reasons could be invoked to implement such features? |
|
@stof Another example, you have a client/server orientation regarding the Recipes, but for private repositories, and as I have already explained (see this issue #71 and this comment), it is preferable to support all the possibilities of Composer, ie to include the use of VCS Repositories. A plugin extending Flex could precisely bring this support. Or other example, allow to have recipes in local. @Pierstoval As I said in this comment, I see much more Symfony Flex as a great automation tool to standardize the project configuration system, than a simple tool dedicated to Symfony, despite what the team say, and even if you have added directly into the plugin a special configurator for the Symfony Bundles ( To be more precise in a use case, take the open source project Grav. It uses the Symfony components, Composer, but they have developed a complete package management system outside of Composer to manage the installation, update, and removal of Plugins and Themes for Grav. Why? because there is currently no solid basis for automating this type of task. Consequently, Composer is used only to install the dependencies of Grav, but not for the Plugins and Themes ... Another example, in the same type but with a different approach: OroCRM / OroPlatform. About me, and as I already mentioned in the related comments, I didn't wait Symfony Flex to create this feature, and so I use a Composer plugin to do it. However why my plugin is it not public? Simply because it isn't "standard" to Symfony, but only for my project, that it isn't public. Of course, I could go out the base, and put it in open-source, but I considered at the time not having the time to support this kind of tool, and now, Symfony Flex could be this base. So, to summarize a use case: authorise the creation of recipes allowing to set up a system of management of the components specific to a project (eg plugins, themes, NPM asset dependencies, etc ...) based on the recipes of Flex. I repeat myself, but Symfony have the the power to carry this kind of tool, we only have to see what you're doing with all Symfony components used by many open-source or proprietary projects, Or your participation in PSR to be convinced. I think that a "standardized" and extensible automation tool would be great, but for that, we must accept more flexibility and openness to ideas that we had not especially had at the outset. So, that's why I think Flex should allow the possibility of extending it, to allow other projects to do things that the developers did not imagined at the beginning. When very good tools exist, but which is lacking some small features to do great things, why reinvent the wheel? Especially that there is no break in compatibility, and not much new code. |
|
For the implementation, maybe replace my proposal:
For In this way a plugin can add new fields to the recipe from sources other than the official server. |
|
Depending of several servers will slow down the installation process and affect the reliability of the whole system. |
|
@dunglas I'm not for a server regarding private recipes (see my proposal #71), but in the case where a server is set up, 1 request at 200/400 ms, this is not a disturbing slowdown! In addition, this does not concern Flex, but the creators of Composer plugins. In the same way you can add Satis servers to Composer (or VCS Repositories). It's not the team of Composer that have a problem if your Satis server is down or is slow. I'm sorry, but without custom servers, or a recipe in the package, what is your solution for the private repositories? This proposal allows the possibility for everyone to extend the functionalities of Flex to create recipes customized to his project, to retrieve the recipes from another server (already proposed by the members of the team of Flex, see all comments of #70), or in a other location. And so, to create a custom automation tools for the project configuration. I am pleased to note that Symfony is heavily and increasingly inspired by what is best in the javascript world, and I can only adhere to it. And to get there, you've created this tool, Awesome! But what astonishes me is that the tool is limited, not because it is young, but by choice (In relation to the explanation given, but I'm probably wrong, and I hope ;)). However, adding flexibility isn't the fundamental principle of this Composer plugin??? |
|
@francoispluchino Nothing prevents you to use the Contrary to what you say, Flex is not made for Symfony but for Composer packages. You can use it without plugging your app to Symfony packages. If you're creating an open-source CMS that have a If it's all about creating new configurators, then I suggest you to create a custom Composer plugin for this, as everything "too specific" may probably not be handled by Flex. |
|
@Pierstoval What I have already said, we reinvent the wheel, having 95% of the code realizing the same tasks, but we already had this conversation (look at my answer to your comments). And I never said that Flex was only for Symfony, precisely, I very good understood that the objective was to create a generic tool to automate the configuration! My proposal makes it possible to integrate additional actions into the Flex configuration process, because I think that Flex is a good common base for doing so. Furthermore, my project isn't open-source... So, your server isn't useful, and I need to perform additional actions to the file copy (run process). So, configurators My proposal is light in modification, and would allow to extend the functionalities of Flex by being able to adapt finely to each project, whether the project is open source or proprietary. What are the real reasons for not accepting this improvement? No new features is added in Flex (like docker config, recipe living in the package, private recipe, ...), only the ability to extend Flex is added, leaving everyone with the ability to add the features it require. |
|
I summarize in this comment the interesting discussions about this feature from other issues: |
|
@fabpot As a follow-up to the discussion on PR #426 and the opportunity to extend Flex, I'm reopening this discussion because we're starting to see more and more projects wanting to use Flex as a base. But given that it is not possible to extend Flex through another Composer plugin, we are starting to see forks like as HarmonyCMS, or specific built-in workarounds in Flex that you just merged with PR #426. I think it is now reasonable to reopen this issue, mostly after Flex's 2 years of maturity and a growing demand from the community to use Flex as a solid foundation. As I have already said many times, do not see my messages as negative, far from it, but I do not understand the integration of Sylius responding to a specific case, giving at the same time additional code to maintain while prohibiting the use of your great tool in the smaller projects. We have to fork Flex or to hack it, we have to make specific integrations in Flex for some selected projects, etc ... which generates a lot of frustration and duplicated work for many, while having a bursting of the Flex project through different alternatives. You rightly indicate in your comment:
On this point, I join you given that it was already one of my arguments to add this feature (cf. this comment and this comment). So, it become necessary to take an interest in this issue, and it would be great to see this capability in Flex, to allowing a fair access to Flex features for all projects whether large or small, open source or proprietary. So please, can you reconsider this feature, and give us the opportunity to disscute what we need, and what you accept as an extension possibility. Is it now possible to do it? Thank you again for your great work and that of all contributors. |
It would be very interesting to be able to extend the features of Flex with other plugin Composer. This would allow for example to add a new configuration specific to a project, or to set up recipes for private repositories (see #71).
You will find in this comment of the issue #70, the reasons and arguments to make Symfony Flex more flexible, in report with this proposal.
For this, it would be quick and simple to implement the Composer event dispatcher in Flex, enabling:
flex.fetch_recipebefore the construction of the new recipe (for each installed/updated package)flex.init(to replace the below components)Configurator(to extend features, like Composer)Downloader(to extend features, like Composer)It would also be necessary to add:
Configurator::update($recipe), and use it in the switch caseinstall/update/uninstall(because, the switch caseupdateis empty currently).Flex::setConfigurator($configurator)to replace the configuratorFlex::setDownloader($downloader)to replace the downloaderAre you interested by this feature? If so, I can quickly offer you a pull request.
The text was updated successfully, but these errors were encountered: