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 <m...@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 <bd...@wikimedia.org> wrote:
> On Tue, May 27, 2014 at 2:56 AM, Tony Thomas <01tonytho...@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
> > on including external libraries.
> >
> > [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=63483
>
> 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 <bd...@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@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
