Also, please note that includes/lib is meant to be a place for external
libraries. Some of the libraries are ones we have ported or written
ourselves, but we should continue using this space as external libraries
increase in number and change in nature.
- Trevor
On Tue, May 27, 2014 at 9:12 AM, Tony Thomas <01tonythomas(a)gmail.com> wrote:
That sounds great Bryan.
I think we should create a new repository in
gerrit
("mediawiki/core/contrib"?
waiting for that repo to show up in gerrit.
On Tue, May 27, 2014 at 7:38 PM, Mark A. Hershberger <mah(a)nichework.com>
wrote:
Thank you! I think the more use we make of
composer, the better.
I do have one concern about the tarballs we
produce.
It looks like it will be necessary to pre-populate
vendor with
composer.json dependencies like this one -- libraries that are essential
-- in order to make sure that a tarball installation require downloading
anything but the tarball itself.
So, if we can have the swiftmailer repo added, this would be excellent. It
might get worse
otherwise, as after this shift, MW can 'only' send emails through swift. A
hard dependency,
as you quoted earlier.
Thanks,
Tony Thomas <http://tttwrites.in>
FOSS@Amrita <http://foss.amrita.ac.in>
*"where there is a wifi, there is a way"*
On Tue, May 27, 2014 at 9:27 PM, Bryan Davis <bd808(a)wikimedia.org> wrote:
On Tue, May 27, 2014 at 2:56 AM, Tony Thomas
<01tonythomas(a)gmail.com>
wrote:
Hi,
We were having discussions regarding putting the new
SwiftMailer[1] lib in/out of core, after the merge of the change
https://gerrit.wikimedia.org/r/#/c/135290. Tyler recommends to add the
installer code to the composer.json and not to add the SwiftMailer code
to
> the core. This creates the swiftmailer lib in core/vendors/swiftmailer.
> After discussing with Bryan (
https://dpaste.de/XVkL/raw), it looks
> like *maintaining
> a separate repo* for external libraries looked like the best solution,
so
> that it uses composer 'properly',
and still works for wmf-deployement
--
rather
than getting the whole into core. It could be thus deployed via
trebuchet to the cluster and the autoloader pulled in in CommonSetings
(quoting Bryan).
Since the entire mail structure is being reworded to use
swiftmailer, and its a crucial dependancy ( There will be no alternate
mail
systems in UserMailer.php -- as both the SMTP and
no SMTP cases are
handled
effectively by SwiftMailer ), I think we will
need to have a separate
repo
> for that. Please go through the patch-set above and comment your
opinions
Thanks for getting this discussion started Tony. I have "been meaning
to" write a very similar email regarding discussions from the Zürich
hackathon about my own attempt to pull third-party libraries into
mediawiki-core [2]. After talking to Ori, Tyler, Matt Walker and
others in Zürich I realized that my desire to put the libraries into
mediawiki-core was mostly motivated by convenience for deployment on
the production wiki[mp]edia cluster. For a variety of reasons, using
composer to download and install libraries directly on the production
cluster is undesirable. There is an alternative however that can be
clearly seen in the mediawiki/extensions/Parsoid/js/contrib.git
repository.
I think we should create a new repository in gerrit
("mediawiki/core/contrib"? Bikeshed as needed) where composer is used
to manage importing specific versions of external libraries that are
needed for the wiki[mp]edia cluster deployments. This repository can
be deployed to the production cluster using Trebuchet or scap and
appropriate changes can be made in operations/mediawiki-config.git to
ensure that the autoloader can find the external classes.
[2]:
https://gerrit.wikimedia.org/r/#/c/119939/
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l