@Alkarex thank you for the details!

it is really not something I would like to use in our case

I respect this. It seems to me that you consider vendor code as code you own like your project code.
It's not my position, as soon as the vendor is trusted and verified.
maybe that's why we will not agree for this project :)

I will open a more complete discussion about modernizing FreshRSS, with my vision, to get your feedback

@Frenzie

I would suggest giving arguments in favor when proposing something. I.e., how would life improve by using Composer to manage two (!) libraries?

Sure. Let's say you are working on a library that comes with its own cache implementation. This cache implementation is actually out of scope of your library and you would like to delete your own implementation. But you still want to allow your users to put their own cache implementation into your library.

Fortunately, there is a standard recommendation for this: PSR-16. You can simply install it with Composer: php composer.phar require psr/simple-cache and then program against the interfaces in your library. Next you can simply delete your cache implementation (or implement a simple fake cache), which disables caching by default. If your users want the library to use a cache, then you simply tell them to inject a PSR-16 implementation in your library.

With this you have created only 1 (!) Composer dependency in your library. In fact, in this example you only have a dependency on interfaces, not classes. But with this you have improved life for everyone:

1. the user can use his own cache implementation.
2. you as library maintainer can delete code and have less code to maintain.
3. the user can change the cache implementation at any time if something is wrong with it. You as library maintainer are absolutely not affected anymore.

I'm not convinced any of that is even tangentially relevant here, but that's an interesting example nonetheless. ^_^

@Frenzie

I'm not convinced any of that is even tangentially relevant here, but that's an interesting example nonetheless. ^_^

Thank you. Then I would like to be more specific about how this example will directly affect FreshRSS in the future. I came across this discussion because I am a contributor to SimplePie and want to understand more how SimplePie is used in projects.

With SimplePie 1.6, there is initial support for namespaces and PSR-4, see #711. The next step will be to deprecate the use of SimplePie without namespaces (because PSR-0 is deprecated too), see #722.

After that, it will be possible to write the cache implementation against PSR-16 interfaces, as explained in my example. And also the HTTP requests can run over an HTTP library thanks to PSR-7, see #520. But for this it will be necessary to have the PSR interfaces in the code. Instead of setting them hard in the code, they will be installed via Composer.

In FreshRSS, a fork of SimplePie is used, incorporating the major changes from SimplePie. This will become more complicated in the future because of the development described above and will require more work.

Like here at FreshRSS, I used to manage dependencies in my projects without Composer for years until I understood Composer deeply enough. I could have saved myself years of work by going straight to Composer. Still, it was worth that work to me because I had to dig deep into Composer and I learned a lot.

So I understand that you are skeptical about Composer at first. Your point that it is easy to accumulate way too many dependencies, I can absolutely understand. But that is not a problem or the responsibility of Composer, but of the developer. And in my example I showed how a wisely taken dependency can lead to less, rather than more dependencies.

I don't want to say that Composer is always and everywhere the best solution, but especially for FreshRSS I see Composer as the right tool. So I would strongly encourage you to look deeper into Composer as a dependency manager as soon as possible. Using it in the dev environment like @Alkarex said is an important first step. 👍

I already covered all off the above in "For just a handful of libraries it's added complexity, unless the one library you're depending on has a million dependencies." and "which is a necessary evil once you get past a certain point." ;-)

Like here at FreshRSS, I used to manage dependencies in my projects without Composer for years until I understood Composer deeply enough. I could have saved myself years of work by going straight to Composer. Still, it was worth that work to me because I had to dig deep into Composer and I learned a lot.

We all use Composer, PyPI, LuaRocks, NPM, Gradle, etc. It's not an unknown entity.