On 2015-02-14 1:23 PM, Gergo Tisza wrote:
As I mentioned this tool is a workaround to deal with current reality.
Not the "grand way forward".
Whenever that happens, the tool will disappear.
The goal here is to make it so that whenever I (or someone else) has to
mange the extensions of an extension (setting up a staging wiki for a
client project, upgrading the extensions on one of the wiki I host, or
upgrade) today, the job is easier to do until we have
a nice web interface for it.
Personally I think we should standardize around one
tool and Composer seems
the best positioned for that. So instead of maintaining N competing
solutions with different strengths and weaknesses and leave the user to
ponder which one to use, I think it would make more sense to focus on the
holes in the Composer workflow and write small tools to plug them (e.g. a
web interface to use Composer on servers without a shell access, or a way
to disable/re-enable extensions without fully uninstalling them).
believe that composer is the grand way forward.
-- TL;DR --
I do believe that composer is a great way to use 3rd party extensions.
However I do not believe it is the way forward in extension installation.
Extensions/plugins are not libraries.
Frankly I want to give whoever built the addition to Composer that
allows packages to install as WordPress plugins and MediaWiki extensions
a good kick.
Besides other things like all our extensions being hosted by a third
party and mixed in with libraries where they don't belong. Composer
doesn't even expose all the data we need to do a PROPER extension
i18n-ed name and description, extension type, and MediaWiki.org
primarily, but there will likely be more.
-- / TL;DR --
In that spirit, maybe writing a composer.json (or
could be a good way of making the extension + git branch selection user
friendly? Once you know which version of which extension to install,
Composer should be able to do the job. The generator could even be a web
service with a nice GUI, like the short url builder (which rocks by the
way, thanks for maintaining it!)
As I don't believe composer is the right way
forward, building something
to try and get everyone to use it would be counter-productive.
Anyways we likely wouldn't get all extensions to start using it. We have
over 600 extensions. And not everyone even buys into composer.
I'd still have the same problem.
Even if it did work I'd end up creating new problems for myself. Now
every time I want to install 'ParserFunctions' I'd have to look up what
the composer name for it is.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/