On 03/09/2016 15:56, Lester Caine wrote:
On 03/09/16 11:20, Rowan Collins wrote:
Interesting, can you give any details of these problems?
https://sourceforge.net/p/tikiwiki/mailman/message/35331374/
Right, so their problem was not with Composer itself, but with Satis,
which is a tool for publishing or mirroring your own packages, like
running your own PEAR channel. They wanted to update it for some reason,
but couldn't because the server had a really old version of PHP, because
it was running a really old version of Ubuntu. Elsewhere in the thread,
they have problems downloading a particular version of a package from
SourceForge. None of this sounds like something that PEAR, or any other
alternative to Composer, would help with.
So you don't like that the tool defaults to giving you a warning,
which can be suppressed, to explain why it might seem slow, due to a
debugging tool documented as not being suitable for production
because it may have a performance impact? I imagine PEAR runs slower
as well, it just doesn't default to telling you so.
But being able to set up an environment where it is easy to switch tools
on and off is being complicated by having to manage different 'composer'
setups. Something which I don't think it was actually designed to handle?
I'm not sure what you mean by that. Composer itself is distributed as a
single PHAR file, and is governed almost entirely by the composer.json
in your project, and pretty much everything can be different in every
project. It's an awful lot easier to have multiple setups of that than
PEAR, which is absolutely designed to manage central system-wide packages.
Do you mean having a single codebase that can be installed with or without composer?
Mostly that's just a case of creating alternative autoloader / bootstrap files, since all
the code knows about composer at runtime is "require 'vendor/autoload.php';"
This is perhaps my sticking point. I have a perfectly stable framework
without the need for any 'autoloader', and a folder structure that
works. Reworking the whole framework so that it follows the 'vendor'
rules while still also just working with bog standard require_once in
the right place is where I keep coming unstuck.
Right, I remember switching to using an autoloader (long long before
composer existed), and what a relief it was not to have to manage great
lists of require_once everywhere any more. :) I think the only thing we
had to fix was some class names being used as lower-case, when the
filenames that needed including were camel-case. The simplest migration
that occurs to me is "if ( file_exists('vendor/autoload.php') ) {
require_once 'vendor/autoload.php'; } else { /* require all the
individual dependencies as before */ }".
What kind of support are we talking about here? My experience of PEAR is "pear install
foo" and in composer that would be "composer require somebody/foo", so I'm
interested which scenarios you think need extra work.
I WAS using SUSE's software management to keep all my production
machines working cleanly. Currently that provides 5.6.9 along with every
pear package I use.
OK, so short story: you're not invoking pear directly anyway, so Davey's
proposal to remove it won't actually affect you at all.
Although I will ALWAYS prefer supplying the distributed library files I need
from a
local server rather than assuming they will remain available from some
third party site, and it's that which I can't do with composer?
That's pretty much what Satis is for, as mentioned above. Or, if you're
willing to pay, Toran Proxy, which is how Jordi gets the money to
improve Composer.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
