On 2014-06-11, 10:55 PM, Tim Starling wrote:
On 11/06/14 16:18, Daniel Friesen wrote:
- And, ;) making PEAR Mail installable via Composer *snicker*
You snicker at the idea that the maintainers of PEAR Mail are not
soldiers in a pitched battle for the minds of developers, PEAR on one
side
It seems worth looking into PEAR mail in my opinion. There something to be
said for a certain minimalism in libraries.
--
View this message in context:
http://wikimedia.7.x6.nabble.com/Making-a-plain-MW-core-git-clone-not-be-installable-tp5029976p5030123.html
Sent from the Wikipedia Developers
(anonymous) wrote:
- needs to install composer
This is one of my pet peeves. It's one thing to have to install
dependencies to run MediaWiki, but having to install various dependencies
just to *install* it? Ugh!
Composer is a first step. [..]
composer is being more and more used in the
On 2014-06-10, 8:59 PM, John wrote:
There is zero reason that this shouldnt be in an extension.
Basically a few users want to install a shinny new toy called swiftmailer
into core, just because its shiny. In doing so they add a complexity and
headache. Such a addition should be done as an
On 11/06/14 16:18, Daniel Friesen wrote:
- ((In other words, the library we're entrusting all our SMTP handling
to is practically dead and no longer maintained, Whoops.))
Only 3 open bugs though. Sometimes code just keeps working for
decades, even without being maintained. Some might even
On 11.06.2014 9:01, Matthew Walker wrote:
This also has knock on impacts elsewhere. BD808 has a patch that uses
PSR-log and Monolog for logging. We're starting to move to a model where we
recognize that we shouldn't write everything and that things in core have
significantly better replacements
Hi,
from my point of view this discussion mixes two or three different questions:
* Do we want core to regularly use external libraries (which are
installed via one git submodule or composer)?
* Should Swiftmailer be used in core?
* (How) Do we want to handle this for plain git cloning to be
Just to add to the technical stuff:-
* We made a local repo to fork the original swiftmailer repo at
https://github.com/wikimedia/mediawiki-core-vendor-swiftmailer/tree/5.2.0-patch,
and our https://gerrit.wikimedia.org/r/#/c/137538/ makes composer take up
the files from our repo and not the
On 2014-06-11, 12:07 AM, Tim Starling wrote:
On 11/06/14 16:18, Daniel Friesen wrote:
- ((In other words, the library we're entrusting all our SMTP handling
to is practically dead and no longer maintained, Whoops.))
Only 3 open bugs though. Sometimes code just keeps working for
decades,
Le 11/06/2014 04:30, Tim Starling a écrit :
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git clone of the MW core not be
installable until $IP/vendor is populated somehow -- either by
separately cloning the mediawiki/core/vendor project, or
On Wed, Jun 11, 2014 at 1:58 PM, Antoine Musso hashar+...@free.fr wrote:
A rough comparison on top of my mind, should probably start up a formal
RFC about it though they are probably some going on.
Please find Bryan's RFC here:-
On Wed, Jun 11, 2014 at 4:28 AM, Antoine Musso hashar+...@free.fr wrote:
- depends on upstream to incorporate our patches
- might not be used as-is on Wikimedia cluster
I would just like to point out that you can override where Composer finds
packages using the composer.json file. In other
Romeo tylerro...@gmail.com
Date: June 11, 2014 at 7:21:46
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject: Re: [Wikitech-l] Making a plain MW core git clone not be installable
On Wed, Jun 11, 2014 at 4:28 AM, Antoine Musso hashar+...@free.fr wrote:
- depends on upstream
On Wed, Jun 11, 2014 at 4:28 AM, Antoine Musso hashar+...@free.fr wrote:
== git submodule ==
+ command already available
+ already used by Wikimedia to handle extensions dependencies in the
wmf branches
+ let us review the code
+ ability to patch third parties
- require to fully clone
I will mention that any solution short of sucking in the third party
dependencies into the main repo (not as a submodule) -- which no one
wants to do anyway -- will be slightly awkward to git bisect. Not
impossible; the pain is about the same for both main options:
a) in theory git-bisect should
I'm not a developer so it's perfectly normal that I can't understand
anything about your talk; nevertheless, please, remember of KISS principle
when building any installing tools for poor, final users. I'm waiting for
something like pip install core.
Alex
2014-06-11 15:58 GMT+02:00 C. Scott
On Wed, Jun 11, 2014 at 10:51 AM, Tyler Romeo tylerro...@gmail.com wrote:
curl -sS https://getcomposer.org/installer | php
... That's just awful.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On Wed, Jun 11, 2014 at 10:42 AM, Alex Brollo alex.bro...@gmail.com wrote:
I'm not a developer so it's perfectly normal that I can't understand
anything about your talk; nevertheless, please, remember of KISS principle
when building any installing tools for poor, final users. I'm waiting for
On Wed, Jun 11, 2014 at 10:56 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
... That's just awful.
How so?
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
___
Wikitech-l mailing list
Fwiw, that's not required. Lots of packages exist already. Even if you
don't have a package for your chosen distro you can easily install it to
your $PATH in less scary ways.
-Chad
On Jun 11, 2014 7:56 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
On Wed, Jun 11, 2014 at 10:51 AM, Tyler
On Wed, Jun 11, 2014 at 10:58 AM, Tyler Romeo tylerro...@gmail.com wrote:
On Wed, Jun 11, 2014 at 10:56 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
... That's just awful.
How so?
Well, it makes *me* wince because you're directing people to pull code
over the network and feed it
Ouch, thanks for wasting a few of my brain cells. This is why do dont add
stupid code to core.
My web server doesnt have curl installed, nor does it have /usr/bin/local/
You havent bothered to think your code through. Why dont you un-fuck your
code, configure it as an extension and go from
On Wed, Jun 11, 2014 at 11:05 AM, Zack Weinberg za...@cmu.edu wrote:
Well, it makes *me* wince because you're directing people to pull code
over the network and feed it straight to the PHP interpreter, probably
as root, without inspecting it first. And the site is happy to send
it to you via
Can we kill the subthread dealing with the awful pipe the output of
curl to php install for composer? It's evilness is not really on
topic (not until we start writing suggested install directions in the
wiki). As Chad noted, there are sane-sysadmin ways to install
composer. I think it would be
On Wed, Jun 11, 2014 at 11:21 AM, Tyler Romeo tylerro...@gmail.com wrote:
It's over HTTPS. As long as you trust that getcomposer.org is the domain
you are looking for, this is really no different than installing via a
package manager.
Nothing stops you from installing it over insecure HTTP.
No one has really addressed the point of making this an extension and not
adding the excessive overhead to core.
Especially for something that may have such a wide impact.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
at 11:47:34
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject: Re: [Wikitech-l] Making a plain MW core git clone not be installable
Nothing stops you from installing it over insecure HTTP. (I filed
https://github.com/composer/composer/issues/3047 for that.)
But this is bad practice
Le 11/06/2014 15:51, Brad Jorsch (Anomie) a écrit :
- require to fully clone each repositories
Couldn't you do a shallow clone, if the disk space or bandwidth is a
concern?
The git submodule add|update subcommands support --depth to produce
shallow clone.
The commit:
Le 11/06/2014 15:51, Brad Jorsch (Anomie) a écrit :
- needs to install composer
This is one of my pet peeves. It's one thing to have to install
dependencies to run MediaWiki, but having to install various dependencies
just to *install* it? Ugh!
Composer is a first step. Then there's
On 11 Jun 2014, at 22:05, Antoine Musso hashar+...@free.fr wrote:
Le 11/06/2014 15:51, Brad Jorsch (Anomie) a écrit :
- needs to install composer
This is one of my pet peeves. It's one thing to have to install
dependencies to run MediaWiki, but having to install various dependencies
just
On 11/06/14 05:01, Matthew Walker wrote:
This also has knock on impacts elsewhere. BD808 has a patch that uses
PSR-log and Monolog for logging. We're starting to move to a model where we
recognize that we shouldn't write everything and that things in core have
significantly better replacements
On Wed, Jun 11, 2014 at 7:20 PM, Isarra Yos zhoris...@gmail.com wrote:
Problem with composer is it doesn't actually work for all use cases (farms
in particular can be problematic, even if the wmf did get it working), so
depending on it isn't really a good idea unless there is a sane fallback.
On 11/06/14 23:21, Tyler Romeo wrote:
On Wed, Jun 11, 2014 at 7:20 PM, Isarra Yos zhoris...@gmail.com wrote:
Problem with composer is it doesn't actually work for all use cases (farms
in particular can be problematic, even if the wmf did get it working), so
depending on it isn't really a good
On 11/06/14 14:49, I wrote:
In particular, there is a mail library called SwiftMailer which
provides bounce detection, among other things. Bounce detection would
be a nice thing to have.
Sorry, it seems I was misled on this. SwiftMailer does not have any
special handling for bounces, judging
On 11/06/14 16:18, Daniel Friesen wrote:
- Current stable 1.2.0, released in March of 2010
Note that the SMTP part is implemented in Net_SMTP, which was last
released in 2013, and the MIME printer part (which we don't currently
use) is in Mail_Mime, last released May 2014.
Swift, by contrast,
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git clone of the MW core not be
installable until $IP/vendor is populated somehow -- either by
separately cloning the mediawiki/core/vendor project, or preferably by
running composer to obtain
On 11/06/14 02:30, Tim Starling wrote:
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git clone of the MW core not be
installable until $IP/vendor is populated somehow -- either by
separately cloning the mediawiki/core/vendor project, or
there is currently a patch in gerrit which would do exactly that if merged.
On Tue, Jun 10, 2014 at 11:22 PM, Isarra Yos zhoris...@gmail.com wrote:
On 11/06/14 02:30, Tim Starling wrote:
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git
On 11/06/14 03:24, John wrote:
there is currently a patch in gerrit which would do exactly that if merged.
Why?
This sounds like a really bad idea, but maybe it isn't, and as a
sysadmin and developer I need to know what it even is so I can decide if
I should flip the fuck out. Or not.
-I
My suggestion, Flip the fuck out Its a really bad idea that wasnt thought
though, If users want SwiftMailer support it should be done in an
extension, and not in core
On Tue, Jun 10, 2014 at 11:30 PM, Isarra Yos zhoris...@gmail.com wrote:
On 11/06/14 03:24, John wrote:
there is currently a
On 2014-06-10, 7:30 PM, Tim Starling wrote:
I have suggested, as a compromise, to make the vendor directory be a
submodule pointing to mediawiki/core/vendor. Then users can either run
git submodule update --init to obtain dependencies, or they can omit
submodule initialisation and instead run
What about doing the reasonable thing and leaving core the hell alone? this
should be an extension and not shoved into core.
On Tue, Jun 10, 2014 at 11:43 PM, Daniel Friesen dan...@nadir-seen-fire.com
wrote:
On 2014-06-10, 7:30 PM, Tim Starling wrote:
I have suggested, as a compromise, to
On 11/06/14 03:31, John wrote:
My suggestion, Flip the fuck out Its a really bad idea that wasnt thought
though, If users want SwiftMailer support it should be done in an
extension, and not in core
On Tue, Jun 10, 2014 at 11:30 PM, Isarra Yos zhoris...@gmail.com wrote:
Okay, so I'm completely
There is zero reason that this shouldnt be in an extension.
Basically a few users want to install a shinny new toy called swiftmailer
into core, just because its shiny. In doing so they add a complexity and
headache. Such a addition should be done as an extension
On Tue, Jun 10, 2014 at 11:55
On 11/06/14 13:22, Isarra Yos wrote:
That's a lot of discussion, and I'm not sure which bits are actually
relevant here, so to clarify - are you saying that it's been proposed
that MediaWiki not be installable from git without extra steps? If so,
what would be the purpose of that?
In the
This also has knock on impacts elsewhere. BD808 has a patch that uses
PSR-log and Monolog for logging. We're starting to move to a model where we
recognize that we shouldn't write everything and that things in core have
significantly better replacements in the wider PHP community. It doesn't
make
46 matches
Mail list logo
