remove laminas/laminas-loader

[arhimede]

Feature Request

Q	A
New Feature	yes
RFC	yes
BC Break	yes

Summary

Since laminas/laminas-loader is abandoned, we should remove it from composer.json

[laminas-bot]

This package is considered feature-complete, and is now in security-only maintenance mode, following a decision by the Technical Steering Committee.
If you have a security issue, please follow our security reporting guidelines.
If you wish to take on the role of maintainer, please nominate yourself

You can continue using laminas/laminas-http safely.
Its successor will be PSR-7 in a later revision of laminas/laminas-mvc.

[arhimede]

yeah, it is not necessary a new release , the issue will be fixed downstream

[froschdesign]

@arhimede

yeah, it is not necessary a new release , the issue will be fixed downstream

laminas-loader must be removed but this needs also a replacement for HeaderLoader:

laminas-http/src/HeaderLoader.php

Lines 3 to 10 in a66bfb6

	namespace Laminas\Http;
	use Laminas\Loader\PluginClassLoader;
	/**
	* Plugin Class Loader implementation for HTTP headers
	*/
	class HeaderLoader extends PluginClassLoader

[arhimede]

@froschdesign then what should we do here, since this package is in security-only mode ?
Should we have a new release of it, still ?

[froschdesign]

@arhimede

…since this package is in security-only mode ?

Is not! See your own polls. 😄

[gsteel]

We voted not to abandon this one. It's integral to MVC so we can't just kill it off. I don't understand the need to deal with the abandonment of the loader library - instead we should focus on eradicating the use of this library in all dependents so that we can abandon it at a future date… which is gonna take a while…

[arhimede]

@arhimede

…since this package is in security-only mode ?

Is not! See your own polls. 😄

I saw that , but Laminas bot closed automatically this issue because "security-only"
#88 (comment)
Do we have an issue with laminas-bot ?

[froschdesign]

Do we have an issue with laminas-bot ?

No, no problem, but as long as the workflow is still active, the message will keep coming back and issues will be closed: https://github.com/laminas/laminas-http/blob/2.21.x/.github/workflows/auto-close.yml

[arhimede]

Do we have an issue with laminas-bot ?

No, no problem, but as long as the workflow is still active, the message will keep coming back and issues will be closed: https://github.com/laminas/laminas-http/blob/2.21.x/.github/workflows/auto-close.yml

There is an active auto-close Action.
https://github.com/laminas/laminas-http/blob/2.21.x/.github/workflows/auto-close.yml
Should we remove it maybe ?

[froschdesign]

Should we remove it maybe ?

Yes, it needs to be removed.

[arhimede]

ok, @alexmerlin Let's see what we can do here, i re-opened the ticket

[alexmerlin]

I analyzed the code and found that there are 2 places where laminas-loader is being used:

• src/HeaderLoader.php - extends Laminas\Loader\PluginClassLoader which is an implementation of the Laminas\Loader\PluginClassLocator interface
• src/Headers.php - contains $pluginClassLoader which is of type Laminas\Loader\PluginClassLocator

The simplest solution to allow the removal of laminas-loader would be to copy PluginClassLoader and PluginClassLocator inside of laminas-http.
But, being that Headers->setPluginClassLoader() is called from outside of laminas-http, not sure if the caller could be set up to call setPluginClassLoader with the custom HeaderLoader.

@gsteel What do you think?

[gsteel]

Changing the inheritance hierarchy of HeaderLoader will be a BC break, and the reason loader is abandoned is because we have composer now.

Seeing as the inheritance changes would be a BC break, we might as well put the effort in to refactoring HeaderLoader instead so that it doesn't rely on loader at all.

I'm guessing, it turns content-type into Laminas\Http\Header\ContentType or something like that… and allows users to provide custom header implementations for x-my-header to My\Header\ClassName - I would start by re-implementing that feature so that it doesn't require any external dependencies.

Releasing a major just to get rid of loader seems excessive… especially on a lib that is destined to be abandoned itself.

Could we focus effort of ridding other libs of laminas-http instead?

I may be off the mark - it's been a long time since I looked at laminas-http…

[froschdesign]

@gsteel

…especially on a lib that is destined to be abandoned itself.

The vote says something different here too.