Making a plain MW core git clone not be installable

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Making a plain MW core git clone not be installable

Tim Starling-2
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 dependencies.

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 composer.

I would like to hear more comments on this.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Isarra Yos
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 preferably by
> running composer to obtain dependencies.
>
> 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 composer.
>
> I would like to hear more comments on this.
>
> -- Tim Starling
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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?

-I

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

John Doe-27
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 <[hidden email]> 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 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 dependencies.
>>
>> 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 composer.
>>
>> I would like to hear more comments on this.
>>
>> -- Tim Starling
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
> 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?
>
> -I
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Isarra Yos
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

John Doe-27
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 <[hidden email]> wrote:

> 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
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Daniel Friesen-2
In reply to this post by Tim Starling-2
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 composer.
I can only think of one potential pain point with this. If someone does
`composer install` instead of checking out the submodule, won't `git
status` complain about that (by displaying it as a modification to core)?

That said, I don't see the point of having mediawiki/core/vendor without
making it a submodule, so I'm in favour of adding it.

To clarify, without a submodule link you don't know what the correct
commit within mediawiki/core/vendor for the commit of MW you have is
tied to:
- On REL1_## branches simply cloning mediawiki/core/vendor would bring
newer versions of libraries that don't match the one the release was
made for. They could be potentially incompatible breaking the wiki, or
may have bugfixes that hide bugs encountered by tarball users when you
try to verify them.
- And it could be worse for individual commits in master. It should be
possible to `git bisect` anything within core, so we definitely should
make sure every commit knows what commit of mediawiki/core/vendor it
should be using, rather than only ensuring that each of our git heads
has a matching mediawiki/core/vendor head to use.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

John Doe-27
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 <[hidden email]
> wrote:

> 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 composer.
> I can only think of one potential pain point with this. If someone does
> `composer install` instead of checking out the submodule, won't `git
> status` complain about that (by displaying it as a modification to core)?
>
> That said, I don't see the point of having mediawiki/core/vendor without
> making it a submodule, so I'm in favour of adding it.
>
> To clarify, without a submodule link you don't know what the correct
> commit within mediawiki/core/vendor for the commit of MW you have is
> tied to:
> - On REL1_## branches simply cloning mediawiki/core/vendor would bring
> newer versions of libraries that don't match the one the release was
> made for. They could be potentially incompatible breaking the wiki, or
> may have bugfixes that hide bugs encountered by tarball users when you
> try to verify them.
> - And it could be worse for individual commits in master. It should be
> possible to `git bisect` anything within core, so we definitely should
> make sure every commit knows what commit of mediawiki/core/vendor it
> should be using, rather than only ensuring that each of our git heads
> has a matching mediawiki/core/vendor head to use.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Isarra Yos
In reply to this post by John Doe-27
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 <[hidden email]> wrote:

Okay, so I'm completely lost. Is the idea here that SwiftMailer is some
shiny new thing that introduces new features, but also new dependencies
and whatnot, and that MediaWiki as a whole won't work without the
dependencies involved?

If so, does it really need to be in core? And if it doesn't, why isn't
it an extension?

And even if it does need to be in core, why should it mean MediaWiki
should no longer be installable from git? MediaWiki already has
dependencies (which are generally met for all wikis when several are
already installed), and the installation process either allows you to
progress or not depending on whether or not they are met, but it does at
least start out of the box. Why should this be any different? Is this
really a sane transition/requirement for developers running test
instances, for third-party projects running from git, and other users?

And, again, what's the purpose of it in the first place?

-L

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

John Doe-27
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 PM, Isarra Yos <[hidden email]> wrote:

> 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 <[hidden email]> wrote:
>>
>
> Okay, so I'm completely lost. Is the idea here that SwiftMailer is some
> shiny new thing that introduces new features, but also new dependencies and
> whatnot, and that MediaWiki as a whole won't work without the dependencies
> involved?
>
> If so, does it really need to be in core? And if it doesn't, why isn't it
> an extension?
>
> And even if it does need to be in core, why should it mean MediaWiki
> should no longer be installable from git? MediaWiki already has
> dependencies (which are generally met for all wikis when several are
> already installed), and the installation process either allows you to
> progress or not depending on whether or not they are met, but it does at
> least start out of the box. Why should this be any different? Is this
> really a sane transition/requirement for developers running test instances,
> for third-party projects running from git, and other users?
>
> And, again, what's the purpose of it in the first place?
>
> -L
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Tim Starling-2
In reply to this post by Isarra Yos
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 current change, the purpose is to provide a clean, feature-rich
interface which developers can use to send emails.

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. It is proposed that developers use
SwiftMailer directly instead of using a MediaWiki wrapper which
optionally uses SwiftMailer. This would make the MW core smaller and
thus easier to maintain.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Matthew Walker
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 sense to keep maintaining the vastly inferior core components when
more and more core and extensions are going to want to rely on the newer
interfaces and features.

The question Tim posed in the commit comes down to:
* Do we bundle third party dependencies, or
* Do we allow composer to do what it was designed to do and manage the
dependencies for us

~Matt Walker
Wikimedia Foundation
Fundraising Technology Team


On Tue, Jun 10, 2014 at 9:49 PM, Tim Starling <[hidden email]>
wrote:

> 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 current change, the purpose is to provide a clean, feature-rich
> interface which developers can use to send emails.
>
> 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. It is proposed that developers use
> SwiftMailer directly instead of using a MediaWiki wrapper which
> optionally uses SwiftMailer. This would make the MW core smaller and
> thus easier to maintain.
>
> -- Tim Starling
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Daniel Friesen-2
In reply to this post by John Doe-27
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 extension
Sorry but these strawmen are quite annoying, and frankly disrespectful
to the developers trying to improve core.

SwiftMailer is not some toy or shiny trinket, it is a serious and well
maintained library dedicated to sending email from PHP.

Adding it to core is not some new feature that would be better in an
extension.
It is a serious improvement to our core handling of email within PHP
that replaces our crude UserMailer code.

Our current UserMailer code is ridiculous when you look at it.

By default our UserMailer code will just use php's creaky mail() function.
Which has some 'features' like:
- Unpredictable message headers
- Lack of feedback regarding delivery failures
- And this beautiful comment in our codebase:
# PHP's mail() implementation under Windows is somewhat shite, and
# can't handle "Joe Bloggs <[hidden email]>" format email addresses,
# so don't bother generating them

If you want to send email a different way, you could of course instead
use $wgSMTP which:
- First requires you to install PEAR Mail.
  - Who the hell uses PEAR anymore!
  - And don't forget, PEAR is a tool that installs modules globally and
is difficult to impossible to use without shell and even admin access.
  - ;) And this is the hell we put tarball users through, not devs.
- This PEAR Mail library we're relying on to handle all users who can't
use mail() or don't want it's features, here's the dev page:
  - http://pear.php.net/package/Mail
  - Current stable 1.2.0, released in March of 2010
  - Next release, 1.2.1 scheduled release date in January of 2011, never
released.
  - ((In other words, the library we're entrusting all our SMTP handling
to is practically dead and no longer maintained, Whoops.))
  - Admittedly if you hunt down PEAR Mail's github repo there has been a
bit of activity:
    - https://github.com/pear/Mail/commits/trunk
    - But none of this will be installed by pear, it'll only install old
code from 2010 missing fixes for a number of bugs in PEAR Mail
    - The majority of changes in 2014 have been minor/trivial things
(adding travis builds, whitespace fixes)
    - And, ;) making PEAR Mail installable via Composer *snicker*

And to sprinkle this all off, because mail() and PEAR Mail are so
different, half the code in UserMailer::send() is split into two
different large code paths, which is a recipe for maintenance headaches.

Using Swift Mailer on the other hand:
- The library has ample development and maintenance going on:
https://github.com/swiftmailer/swiftmailer/commits/master
- SMTP and mail() are abstracted away into transports, so instead of two
large (unmaintained?) code paths we just craft and send an email in one
code path, a well maintained library takes care of the difference
between transports.
- In the future we can move away from using mail() and add the ability
to use sendmail as a transport directly, without the bugs (in theory I
think it would even be possible to try swapping a different transport in
place of mail() automatically).
- All this gets bundled into the tarball directly, so $wgSMTP now works
out of the box and doesn't require installation of something that in
some situations is impossible to install.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Tim Starling-2
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 call this a goal.

> And to sprinkle this all off, because mail() and PEAR Mail are so
> different, half the code in UserMailer::send() is split into two
> different large code paths, which is a recipe for maintenance headaches.

It's only 50 lines of code each way, which is not quite enough to give
me a headache. It could use refactoring, but it wouldn't take long to
refactor 100 lines of code.

> - All this gets bundled into the tarball directly, so $wgSMTP now works
> out of the box and doesn't require installation of something that in
> some situations is impossible to install.

That is a nice feature, yes.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Dmitriy Sintsov-2
In reply to this post by Matthew Walker
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 in the wider PHP community. It doesn't
> make sense to keep maintaining the vastly inferior core components when
> more and more core and extensions are going to want to rely on the newer
> interfaces and features.
PSR loader is ok. PSR "standard" of using four spaces instead of tabs
for indentation is strange. That prevents from easily adjusting the
indentation (good editors can visually render tabs like N-spaces
according to user preference) and has another drawbacks.

> The question Tim posed in the commit comes down to:
> * Do we bundle third party dependencies, or
> * Do we allow composer to do what it was designed to do and manage the
> dependencies for us
>
>
composer can use git to fetch dependencies, at least it does so when I
developed with symfony2.
https://getcomposer.org/doc/05-repositories.md
Dmitriy


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Adrian Lang
In reply to this post by Tim Starling-2
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 usable?

I think the first question is sort of answered, although maybe not
everybody committed on that.

The second question is something different entirely. From my point of
view it doesn't make any sense to discuss this here, because
(considering how we IMHO answered the first question) we will have a
required dependency eventually, even if that is not going to be
Swiftmailer.

The third question is what Tim actually asked, and it's an
interesting, technical question we should focus on. I like Tim's
suggestion of having an optional git submodule. The installer could
then show an error if vendor/ is missing proposing to either run
"composer install" or "git submodule update --init". Do we also have
to consider composer.lock?

Regards,
Adrian

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Tony Thomas
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 upstream one, which is for the
development end.
* Our VERP project is going on at https://gerrit.wikimedia.org/r/#/c/138655/

Thanks,
Tony Thomas <http://tttwrites.in>
FOSS@Amrita <http://foss.amrita.ac.in>

*"where there is a wifi, there is a way"*


On Wed, Jun 11, 2014 at 1:10 PM, Adrian Lang <[hidden email]>
wrote:

> 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 usable?
>
> I think the first question is sort of answered, although maybe not
> everybody committed on that.
>
> The second question is something different entirely. From my point of
> view it doesn't make any sense to discuss this here, because
> (considering how we IMHO answered the first question) we will have a
> required dependency eventually, even if that is not going to be
> Swiftmailer.
>
> The third question is what Tim actually asked, and it's an
> interesting, technical question we should focus on. I like Tim's
> suggestion of having an optional git submodule. The installer could
> then show an error if vendor/ is missing proposing to either run
> "composer install" or "git submodule update --init". Do we also have
> to consider composer.lock?
>
> Regards,
> Adrian
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Daniel Friesen-2
In reply to this post by Tim Starling-2
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, even without being maintained. Some might even call this a goal.
Well yes, there are only a few (actually 4 not 3) open bugs:
http://pear.php.net/bugs/search.php?cmd=display&package_name[]=Mail&status=OpenFeedback&bug_type=Bugs

Although there's also this:
http://pear.php.net/bugs/roadmap.php?package=Mail&roadmapdetail=1.2.1#a1.2.1

Because 1.2.1 was never released to pear there are 6 extra already fixed
bugs which everyone using PEAR Mail are still affected by.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Antoine Musso-3
In reply to this post by Tim Starling-2
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 preferably by
> running composer to obtain dependencies.
>
> 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 composer.
>
> I would like to hear more comments on this.

Hello,

I would prefer us to avoid embedding third party libraries directly in core:
 - the repository is already big enough as it is (recently Chad proposed
to drop history to shrink the repo).
 - we might be tempted to have local hack and forget to push them back
to upstream

Assuming the above, we would require an extra step and I am fine with
it.  For people running mediawiki out of a git clone that should not be
too much of an hassle, the rest of the user base uses the tarball or a
package which could both embed all the third party libraries.


I do not think we should mix both system and should make a choice
between git submodule and composer.

A rough comparison on top of my mind, should probably start up a formal
RFC about it though they are probably some going on.


== 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 each repositories
- version tracked by git sha1 in .gitmodules instead of a version number


== composer ==

+ generates autoloader entries
+ has a post install system which could be used to inject settings in
LocalSettings.php
+ could be used to handle extensions dependencies
- depends on upstream to incorporate our patches
- needs to install composer
- might not be used as-is on Wikimedia cluster


Before we make any decision, I would love to hear from Bryan Davis (he
is on vacations this week) and Jeroen De Dauw who already put a lot of
efforts on dependencies management.

cheers,

--
Antoine "hashar" Musso


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Tony Thomas
On Wed, Jun 11, 2014 at 1:58 PM, Antoine Musso <[hidden email]> 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:-
https://www.mediawiki.org/wiki/Requests_for_comment/Composer_managed_libraries_for_use_on_WMF_cluster

Thanks,
Tony Thomas <http://tttwrites.in>
FOSS@Amrita <http://foss.amrita.ac.in>

 *"where there is a wifi, there is a way"*
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Making a plain MW core git clone not be installable

Tyler Romeo
In reply to this post by Antoine Musso-3
On Wed, Jun 11, 2014 at 4:28 AM, Antoine Musso <[hidden email]> 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 words, if we wanted to
force Composer to use WMF's git repositories to check out dependencies,
that is entirely possible. In the end, Composer uses git to check out the
packages anyway.

https://getcomposer.org/doc/04-schema.md#repositories

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123