Replies: 1 comment 2 replies
-
Both ways are supported actually. See https://getcomposer.org/doc/articles/scripts.md#defining-scripts for the documentation. |
Beta Was this translation helpful? Give feedback.
-
|
Okay. But only the php callable would run in the same context as composer and would lead to such a problem, right? I actually found out, that my problem was not exactly the same as the issue, but it caused by a very extensive Autoloader from this package and they are working on a solution to get around some of it here open-telemetry/opentelemetry-php#1727. Yet the question remains should hooks and composer share the same dependency context? |
Beta Was this translation helpful? Give feedback.
-
|
Packages that register custom autoload files could do that either because loading their own classes has special requirements (for instance this was the case in SwiftMailer), because they define functions (which cannot be autoloaded in PHP) or because they want to abuse it. Composer has no way to distinguish the third case from the legitimate cases. So it would be the job of those packages doing weird things to support the context of running in the composer context. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Today I stumbled across this issue: #11246
And not like I found it by searching, but first ran into the issue in the wild and then found the issue above.
Sorry to bring this from 2023 up again, but I would not want to create a second issues with the same thing, before talking to folks first.
I do not know how far the supported range for composer goes back into unsupported versions of PHP.
Since PHP 7 has been discontinued shortly after this issue arose, could we consider dropping it or would that be a breaking change and needed a v3?
On the other hand this problem bares the question if hooks should be called INSIDE the same context as the composer process, which as we see above can lead to dependency poisoning/confusion. If the callbacks would spawn in their own process, they could be save from that, but would need a lot more context given into them.
I think this issue should be reopened, since "avoid putting too much logic into your callbacks" is not really feasible and this should be kept in mind for a v3 or maybe earlier, if possible. You can not prevent people for doing this kind of thing and I do not know how, but maybe this could even end badly because of the above mentioned dependency poisoning/confusion.
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions