digital-competence / composer-ebuilds

Gentoo ebuilds for current composer
0 stars 1 forks source link

Autoloaders build with phpab might not work on every system #4

Closed r7l closed 1 year ago

r7l commented 1 year ago

First of, i have to admit not to be an expert for Composer and autoloaders. I am not a PHP developer. More of devops hosting PHP applications (and other stuff). I was reading into it and what Gentoo made out of it, when working on a set of Ebuilds for Composer. Autoloaders on Gentoo (or Fedora) seem to be a bit different then what phpab does by default.

Using phpab does provide a classmap but Gentoo works with Psr4 as provided in composer.json most of the time. The usage of classmaps seem to lead to errors when installing the Composer Ebuilds on a new system. Running any Composer command leads to this output:

PHP Fatal error:  Uncaught Error: Class "Composer\Util\Platform" not found in /usr/share/composer/bin/composer:83
Stack trace:
#0 {main}
  thrown in /usr/share/composer/bin/composer on line 83

Fatal error: Uncaught Error: Class "Composer\Util\Platform" not found in /usr/share/composer/bin/composer:83
Stack trace:
#0 {main}
  thrown in /usr/share/composer/bin/composer on line 83
fcool commented 1 year ago

Wow! I just removed all php packages and reinstalled them - and still cannot reproduce the issue. :( But without reproduction I don't know, where this might come from. :(

Maybe some more BDEPENDS are missing... I will go through the packages once again.

fcool commented 1 year ago

(I just found out, the build to symfony-finder was broken... maybe the problem might come frome there... so as I did not mark the package as updated, you'd need to update it manually by running emerge -v1 symfony-finder )

fcool commented 1 year ago

I guess, I will extend the build of composer to have the "test" use-flag available and will try to build the complete dev-dependency-chain to be able to run the unit-tests. But this way we will get a LOT more packages ;)

fcool commented 1 year ago

Ha! I found a possibility to reproduce the problem. It will trigger when working with "create-project". Even if not "newly" installed. So maybe there is something broken in general. :)

But now the error is observable. Und I guess it will be solvable :)

fcool commented 1 year ago

Oh, oh, oh... I'm sorry.

But the broken autoloader was me by "beautifying" the composer ebuild. I thought in the end I could use the fedora template for composer too... and overlooked, that it had a tiny difference in it.

So it has nothing todo with a new system, but me broke an already working ebuild. :(

Sorry.

Now I fixed all builds and reverted the problem I introduced in composer itself.

And from now on, I will use revision suffixes to mark changes, so that package updates will be automatically picked up.

But installing all of them freshly should lead to a working system now.

Next step would be to ajdust the autoloaders for the "bigger" components to carry their own "requires" the right way and maybe then slim down the autoload-configuration of composer.

But for now we are back to a working state. Sorry for the trouble. :/

r7l commented 1 year ago

Thanks allot for the quick fix. Composer works without issues for now.

I've noticed that it might be possible to simplify the amount of Ebuilds using the the general polyfill package instead of multiple single packages. Wouldn't that be an option? It might even be possible with some sed lines to remove those classes for obsolete PHP version. Other then that, you're using most of what the general package offers anyways.