Tyler Romeo | 25 Sep 19:54 2012
Picon

Re: New extension: Diff

This looks pretty interesting. Is there a reason we don't just put this in
the core?

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo <at> gmail.com

On Tue, Sep 25, 2012 at 6:50 AM, Jeroen De Dauw <jeroendedauw <at> gmail.com>wrote:

> Hey,
>
> I'm happy to announce the first release of a new little extension I wrote
> called Diff.
>
> https://www.mediawiki.org/wiki/Extension:Diff
>
> It's a small utility library which might be of use to anyone creating a new
> extension :)
>
> Cheers
>
> --
> Jeroen De Dauw
> http://www.bn2vs.com
> Don't panic. Don't be evil.
> --
> _______________________________________________
> Wikitech-l mailing list
(Continue reading)

Tim Starling | 26 Sep 04:21 2012
Picon

Re: New extension: Diff

On 26/09/12 03:54, Tyler Romeo wrote:
> This looks pretty interesting. Is there a reason we don't just put this in
> the core?

It has about 50 lines of useful code wrapped in 1600 lines of
abstraction. I don't think it is the sort of style we want in the core.

-- Tim Starling
Denny Vrandečić | 26 Sep 09:22 2012
Picon

Re: New extension: Diff

2012/9/26 Tim Starling <tstarling <at> wikimedia.org>:
> On 26/09/12 03:54, Tyler Romeo wrote:
>> This looks pretty interesting. Is there a reason we don't just put this in
>> the core?
>
> It has about 50 lines of useful code wrapped in 1600 lines of
> abstraction. I don't think it is the sort of style we want in the core.

I am sorry, but I find this comment a bit harsh, and just wanted to
deliver some data on that. Maybe it was meant as a hyperbole, in which
case I apologize for not treating it as such.

The extension has, altogether 2846 total lines of code in 24 files, of
which 332 lines are blank, 1328 lines are comments, and 1186 are
physical lines of code.

Of the latter 1186, 641 are tests. I find that commendable.
(That leaves us with 1663 total lines of code, which are probably the
1600 from the original comment)

Another 148 physical lines go to initializing the extension and
internationalization.

Remain 402 physical lines of code.

Now, one might discuss the suitability of using interfaces in PHP, but
we have that in core: IDBAccessObject, ICacheHelper, IDeviceDetector,
and a few others. Not many, but they exist. Anyway, the two interface
classes account for only 18 physical lines of code anyway.
The only 18 lines a user of the extension needs to care about.
(Continue reading)

Jeroen De Dauw | 26 Sep 11:06 2012
Picon

Re: New extension: Diff

Hey,

> Is there a reason we don't just put this in the core?

One of the reasons is that from my experience the MediaWiki core dev
community is not very open to such things. I think Tim is illustrating the
point pretty well, by implying what I did is total nonsense. Having tried
to get this into core would have lead to more insults getting thrown at my
head. Of course this is nonsense, as I'm sure some core developer will
point out in a reply.

Another reason is that although this is a rather generic diff utility, the
number of extensions that could make use of this seems rather limited. And
I don't think we want to just put any generic component into core without
good reason.

> It has about 50 lines of useful code wrapped in 1600 lines of
> abstraction. I don't think it is the sort of style we want in the core.

Unsurprisingly I'm going to Agree with Denny that this is rather harsh.
This kind of attitude is not very welcoming to other developers, especially
if you make such comments where they are not applicable.

And yes, I'm going to maintain it's not applicable. Being the genius that
you are, I challenge you to put your money where your mount is to write a
50 line extension that offers the same functionality as this extension.

One might discuss the suitability of using a class hierarchy to
> represent different DiffOps. But then again, that is the same class
> design as in the DairikiDiff engine, included in core as well.
(Continue reading)

Krinkle | 26 Sep 19:54 2012
Picon

Re: New extension: Diff

On Sep 25, 2012, at 7:54 PM, Tyler Romeo <tylerromeo <at> gmail.com> wrote:

> Is there a reason we don't just put this in the core?
> 

Many points have been made already in a short amount of time, which emphasizes
how touchy this subject can be.

Anyway, a different view that I haven't heard as much is the following.

Being in core is not a stamp of approval. This picture never existed and if it
did, it needs to go away. We're going towards a flexible modular system, which
means components have dependencies and build on each other - as opposed to just
"being there".

So unless other existing core functionality would need it, it doesn't make sense
to include it.

Instead, extensions should prove themselves. If an extension provides
functionality that other extensions need, those other extensions will simply add
"Make sure X and Y is installed first" to their instructions and use it that
way.

This gives a few advantages:
* Fair competition. Extensions can decide that they want to use, make it also
easy for developers to fork a utility and improve it (like extensions do).
* Flexibility. Once it is in core, we have to support it, which is especially
awkward if it isn't in use, because that means we have an untracked dependency
on something we don't even use, and can't be easily replaced either because some
extension might use it, somehow. 
(Continue reading)

Mark A. Hershberger | 28 Sep 03:47 2012

Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On 09/26/2012 01:54 PM, Krinkle wrote:
> We're going towards a flexible modular system, which
> means components have dependencies and build on each other - as opposed to just
> "being there".

This sounds great, but I do see an important missing piece of
infrastructure.

First, I am absolutely in favor of a loosely-coupled, modular system
instead of just building a larger and larger core.

The problem, though, is that there is no way to install, use, or update
extensions apart from doing it by hand.  Requiring the installation of
multiple modules by hand isn't going to lead to a thriving, modular
ecosystem.  We need a dependency manager.

Thankfully, I think there is already a dependency manager that we can
build on.

I'm talking about Composer (http://getcomposer.org/).

Of course, MediaWiki isn't aware of this dependency manager and so
MediaWiki's extensions aren't either.  I've only looked at it briefly,
but it appears that adding support wouldn't be difficult at all -- it
would just mean adding a file to the git repository.

What do you think?

Mark.
(Continue reading)

Tyler Romeo | 28 Sep 04:01 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

Sounds somewhat viable. I know a number of other projects who use composer.
It would be interesting to try it out.

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo <at> gmail.com

On Thu, Sep 27, 2012 at 9:47 PM, Mark A. Hershberger <mah <at> everybody.org>wrote:

> On 09/26/2012 01:54 PM, Krinkle wrote:
> > We're going towards a flexible modular system, which
> > means components have dependencies and build on each other - as opposed
> to just
> > "being there".
>
> This sounds great, but I do see an important missing piece of
> infrastructure.
>
> First, I am absolutely in favor of a loosely-coupled, modular system
> instead of just building a larger and larger core.
>
> The problem, though, is that there is no way to install, use, or update
> extensions apart from doing it by hand.  Requiring the installation of
> multiple modules by hand isn't going to lead to a thriving, modular
> ecosystem.  We need a dependency manager.
>
> Thankfully, I think there is already a dependency manager that we can
> build on.
(Continue reading)

Daniel Friesen | 28 Sep 04:32 2012

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On Thu, 27 Sep 2012 18:47:41 -0700, Mark A. Hershberger  
<mah <at> everybody.org> wrote:

> On 09/26/2012 01:54 PM, Krinkle wrote:
>> We're going towards a flexible modular system, which
>> means components have dependencies and build on each other - as opposed  
>> to just
>> "being there".
>
> This sounds great, but I do see an important missing piece of
> infrastructure.
>
> First, I am absolutely in favor of a loosely-coupled, modular system
> instead of just building a larger and larger core.
>
> The problem, though, is that there is no way to install, use, or update
> extensions apart from doing it by hand.  Requiring the installation of
> multiple modules by hand isn't going to lead to a thriving, modular
> ecosystem.  We need a dependency manager.
>
> Thankfully, I think there is already a dependency manager that we can
> build on.
>
> I'm talking about Composer (http://getcomposer.org/).
>
> Of course, MediaWiki isn't aware of this dependency manager and so
> MediaWiki's extensions aren't either.  I've only looked at it briefly,
> but it appears that adding support wouldn't be difficult at all -- it
> would just mean adding a file to the git repository.
>
(Continue reading)

Tyler Romeo | 28 Sep 06:10 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

Daniel makes some good points. However, we still do need some sort of
better extension installation system besides our current "clone and
require". So here's some things we might want to consider:

   - Should this be a web-based system or something done with maintenance
   scripts?
   - Extensions should probably have some sort of manifest file. What
   format should it be in and what information should it contain?
   - How would extensions be installed? Would the manifest file be made
   public online and you just reference that file? Or maybe you just give the
   URL of the git repo or tarball of the extension? Or maybe MediaWiki creates
   some sort of repository that can be used? Most likely it'll be a
   combination of the latter two.
   - Would this extension system be part of the core, or an extension
   itself? I personally would side with putting it in the core, but if we're
   going truly modular some will argue otherwise.

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo <at> gmail.com

On Thu, Sep 27, 2012 at 10:32 PM, Daniel Friesen <daniel <at> nadir-seen-fire.com
> wrote:

> On Thu, 27 Sep 2012 18:47:41 -0700, Mark A. Hershberger <mah <at> everybody.org>
> wrote:
>
>  On 09/26/2012 01:54 PM, Krinkle wrote:
(Continue reading)

Daniel Friesen | 28 Sep 07:11 2012

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On Thu, 27 Sep 2012 21:10:40 -0700, Tyler Romeo <tylerromeo <at> gmail.com>  
wrote:

> Daniel makes some good points. However, we still do need some sort of
> better extension installation system besides our current "clone and
> require". So here's some things we might want to consider:
>
>    - Should this be a web-based system or something done with maintenance
>    scripts?
In the end it should be both. A web-based system to install extensions for  
normal users. And cli scripts to install extensions for users maintaining  
piles of wikis.

>    - Extensions should probably have some sort of manifest file. What
>    format should it be in and what information should it contain?
I think Chad (^demon) was the the one focusing on this area. We should ask  
him what his plans were.

>    - How would extensions be installed? Would the manifest file be made
>    public online and you just reference that file? Or maybe you just  
> give the
>    URL of the git repo or tarball of the extension? Or maybe MediaWiki  
> creates
>    some sort of repository that can be used? Most likely it'll be a
>    combination of the latter two.
It should be a real registry of extensions.

>    - Would this extension system be part of the core, or an extension
>    itself? I personally would side with putting it in the core, but if  
> we're
(Continue reading)

Chad | 28 Sep 13:52 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On Fri, Sep 28, 2012 at 1:11 AM, Daniel Friesen
<daniel <at> nadir-seen-fire.com> wrote:
>>    - Extensions should probably have some sort of manifest file. What
>>    format should it be in and what information should it contain?
>
> I think Chad (^demon) was the the one focusing on this area. We should ask
> him what his plans were.
>

I had some rough ideas, but they never got fleshed out. In my ideal
world, I was thinking something like an abstract Extension class
that each extension would implement. It would have methods for
returning things $wgExtensionCredits does now, as well as being
able to say "I depend on Foo" extension. Then we'd have some kind
of ExtensionRegistry, so enabling an extension would be something
like ExtensionRegistry::register( new MyExt );

But yeah, I never really got further than that.

-Chad
Daniel Friesen | 28 Sep 18:29 2012

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On Fri, 28 Sep 2012 04:52:40 -0700, Chad <innocentkiller <at> gmail.com> wrote:

> On Fri, Sep 28, 2012 at 1:11 AM, Daniel Friesen
> <daniel <at> nadir-seen-fire.com> wrote:
>>>    - Extensions should probably have some sort of manifest file. What
>>>    format should it be in and what information should it contain?
>>
>> I think Chad (^demon) was the the one focusing on this area. We should  
>> ask
>> him what his plans were.
>>
>
> I had some rough ideas, but they never got fleshed out. In my ideal
> world, I was thinking something like an abstract Extension class
> that each extension would implement. It would have methods for
> returning things $wgExtensionCredits does now, as well as being
> able to say "I depend on Foo" extension. Then we'd have some kind
> of ExtensionRegistry, so enabling an extension would be something
> like ExtensionRegistry::register( new MyExt );
>
> But yeah, I never really got further than that.
>
> -Chad

Hmmm... I do like the idea of an extension class for some things.
But I think that some of this metadata may be used in places we don't want  
to execute php. So we probably also want a proper flat-file format.

--

-- 
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
(Continue reading)

Mark A. Hershberger | 28 Sep 18:27 2012

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On 09/28/2012 01:11 AM, Daniel Friesen wrote:
> In the end it should be both. A web-based system to install extensions
> for normal users. And cli scripts to install extensions for users
> maintaining piles of wikis.

Agreed.

> I think Chad (^demon) was the the one focusing on this area. We should
> ask him what his plans were.

Working code > great plans.

Chad has replied.  I think he would agree that we don't think we need to
hold back on dependency management to wait for him to produce something.

Indeed, Antoine has already implemented some sort of Composer support to
help him manage the environment he is charged with.  I recommend we
follow his lead and build on that.

This is the whole problem with Cookie Licking.  Productive people have
lots of great ideas, but we shouldn't let ideas get in the way of actual
progress.

And just so it is absolutely clear: I have an enormous amount of respect
for Chad and admire the work he has been doing.  I just don't want us to
put all our hopes on what Chad *plans* to do when we have other people
with ideas and ability.

In other words, Antoine has produced some code that he says works --
let's see if we can use it before we dismiss the whole idea because it
(Continue reading)

Chad | 28 Sep 18:29 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On Fri, Sep 28, 2012 at 12:27 PM, Mark A. Hershberger <mah <at> everybody.org> wrote:
>> I think Chad (^demon) was the the one focusing on this area. We should
>> ask him what his plans were.
>
> Working code > great plans.
>
> Chad has replied.  I think he would agree that we don't think we need to
> hold back on dependency management to wait for him to produce something.
>
> Indeed, Antoine has already implemented some sort of Composer support to
> help him manage the environment he is charged with.  I recommend we
> follow his lead and build on that.
>
> This is the whole problem with Cookie Licking.  Productive people have
> lots of great ideas, but we shouldn't let ideas get in the way of actual
> progress.
>
> And just so it is absolutely clear: I have an enormous amount of respect
> for Chad and admire the work he has been doing.  I just don't want us to
> put all our hopes on what Chad *plans* to do when we have other people
> with ideas and ability.
>

I had plans for this, insofar as I have plans for lots of things.
I've never committed to doing this, so nobody should wait on
me.

-Chad
Sumana Harihareswara | 28 Sep 18:40 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On 09/28/2012 12:29 PM, Chad wrote:
> On Fri, Sep 28, 2012 at 12:27 PM, Mark A. Hershberger <mah <at> everybody.org> wrote:
>>> I think Chad (^demon) was the the one focusing on this area. We should
>>> ask him what his plans were.
>>
>> Working code > great plans.
>>
>> Chad has replied.  I think he would agree that we don't think we need to
>> hold back on dependency management to wait for him to produce something.
>>
>> Indeed, Antoine has already implemented some sort of Composer support to
>> help him manage the environment he is charged with.  I recommend we
>> follow his lead and build on that.
>>
>> This is the whole problem with Cookie Licking.  Productive people have
>> lots of great ideas, but we shouldn't let ideas get in the way of actual
>> progress.
>>
>> And just so it is absolutely clear: I have an enormous amount of respect
>> for Chad and admire the work he has been doing.  I just don't want us to
>> put all our hopes on what Chad *plans* to do when we have other people
>> with ideas and ability.
>>
> 
> I had plans for this, insofar as I have plans for lots of things.
> I've never committed to doing this, so nobody should wait on
> me.
> 
> -Chad

(Continue reading)

Tyler Romeo | 28 Sep 19:05 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

Well in that case maybe we can get some sort of official design document
going so that we're planning rather than plinning. :P

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo <at> gmail.com

On Fri, Sep 28, 2012 at 12:40 PM, Sumana Harihareswara <
sumanah <at> wikimedia.org> wrote:

> On 09/28/2012 12:29 PM, Chad wrote:
> > On Fri, Sep 28, 2012 at 12:27 PM, Mark A. Hershberger <mah <at> everybody.org>
> wrote:
> >>> I think Chad (^demon) was the the one focusing on this area. We should
> >>> ask him what his plans were.
> >>
> >> Working code > great plans.
> >>
> >> Chad has replied.  I think he would agree that we don't think we need to
> >> hold back on dependency management to wait for him to produce something.
> >>
> >> Indeed, Antoine has already implemented some sort of Composer support to
> >> help him manage the environment he is charged with.  I recommend we
> >> follow his lead and build on that.
> >>
> >> This is the whole problem with Cookie Licking.  Productive people have
> >> lots of great ideas, but we shouldn't let ideas get in the way of actual
> >> progress.
(Continue reading)

Mark A. Hershberger | 28 Sep 20:43 2012

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On 09/28/2012 01:05 PM, Tyler Romeo wrote:
> Well in that case maybe we can get some sort of official design document
> going so that we're planning rather than plinning. :P

I'll again point to the work that Antoine has done.  I haven't looked at
it yet (and I won't have time to do that today), but even if he doesn't
have a design document, he has *something* working so were definitely at
(at least) the planning stage by now.

Mark.
Antoine Musso | 1 Oct 08:58 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

Le 28/09/12 18:27, Mark A. Hershberger a écrit :
>> > It should be a real registry of extensions.
> Right now, Composer supports Packagist (http://packagist.org/).  I'm
> sure we could add support for our own registry if we needed.

Packagist itself is OpenSource. There is already Satis, which is a
static repository.

 - https://github.com/composer/packagist
 - https://github.com/composer/satis

I guess it is simpler to use the same repo for now :-) It saves us from
the trouble of maintaining one and users will have extensions out of the
box.

--

-- 
Antoine "hashar" Musso
Stephen Villano | 28 Sep 07:38 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

I'm reminded of an old BBS system I once operated, then beta tested for, then alpha tested and did a bit of
development on. 
It worked on old C=64 systems, hence was heavily memory use intolerant.
We used mini-modules that were swapped in and out of memory, with the main central routines part of the
primary system. One would call upon the primary routines that remained memory-resident, while the rest
would swap in and out as needed.
Yes, I know about current library use, this is memory resident in the core of the system. 
THAT is where we are again today, where one does NOT want monolithic monstrosities clogging up the http
server, nor do we want tangle code beginning to sprout up.
So, the centralized dependency database IS valuable. WITH standards imposed for inclusion, so that we
don't end up with the mess that some packages end up in some Linux distributions, lacking clear dependancies.
One side issue is security, which I'm certain, we'd all agree upon. Where security patches for the code are
also monitored and centrally managed as a required part of the dependencies. Lest some Wikis end up
compromised by malicious code, to share the misery.
Hence, loosely coupled isn't quite the answer, lest either tangle code prevail or insecure code prevail. 

On Sep 27, 2012, at 9:47 PM, Mark A. Hershberger wrote:

> On 09/26/2012 01:54 PM, Krinkle wrote:
>> We're going towards a flexible modular system, which
>> means components have dependencies and build on each other - as opposed to just
>> "being there".
> 
> This sounds great, but I do see an important missing piece of
> infrastructure.
> 
> First, I am absolutely in favor of a loosely-coupled, modular system
> instead of just building a larger and larger core.
> 
> The problem, though, is that there is no way to install, use, or update
(Continue reading)

Antoine Musso | 28 Sep 15:22 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

Le 28/09/12 03:47, Mark A. Hershberger a écrit :
<snip>
> The problem, though, is that there is no way to install, use, or update
> extensions apart from doing it by hand.  Requiring the installation of
> multiple modules by hand isn't going to lead to a thriving, modular
> ecosystem.  We need a dependency manager.
> 
> Thankfully, I think there is already a dependency manager that we can
> build on.
> 
> I'm talking about Composer (http://getcomposer.org/).

I am going to need such a dependency manager for continuous integration
of our extensions. I am not going to maintain a list of each extension
dependency nor am I going to write some piece of code to handle that.
Composer is IMHO a great way to handle our dependencies.

My past experiment is on the wiki at:
  https://www.mediawiki.org/wiki/Composer

The change is not that much invading (it is just about adding a
composer.json file at the root of the extension) and thus is definitely
not going to harm anything. Even if we end up choosing a different
system (PEAR??) or writing our own, that is just a simple json file.

> Of course, MediaWiki isn't aware of this dependency manager and so
> MediaWiki's extensions aren't either.  I've only looked at it briefly,
> but it appears that adding support wouldn't be difficult at all -- it
> would just mean adding a file to the git repository.

(Continue reading)

Mark A. Hershberger | 28 Sep 18:01 2012

Re: Dependency management, MediaWiki and modularity

On 09/28/2012 09:22 AM, Antoine Musso wrote:
>> I'm talking about Composer (http://getcomposer.org/).

> My past experiment is on the wiki at:
>   https://www.mediawiki.org/wiki/Composer

Awesome!

I do agree with David Gerard's assessment, though.  We need to make sure
that whatever we use is going to work with package management tools that
Debian and Redhat and the like already use.

For Debian, there is dh-make-perl and dh-make-php that will turn CPAN
libraries, PECL and PEAR libraries into debian packages automatically.
They don't *always* work, but they're a good start.

Ultimately, dh-make-php should probably support Composer as well.  If
Composer can work with MediaWiki extensions, then all the better.

> And again, adding support for Composer would just need:
>  - write basic code to include the generated autoload file
>  - add some composer.json files in extension roots
> 
> We could start with a subset of extensions.

A great place to start would be the SMW Bundle:

  http://www.mediawiki.org/wiki/Semantic_Bundle

When I was building the tarball, I made an attempt to create a MW
(Continue reading)

David Gerard | 28 Sep 18:05 2012
Picon

Re: Dependency management, MediaWiki and modularity

On 28 September 2012 17:01, Mark A. Hershberger <mah <at> everybody.org> wrote:

> I do agree with David Gerard's assessment, though.  We need to make sure
> that whatever we use is going to work with package management tools that
> Debian and Redhat and the like already use.

The other reason is, of course, making the distro versions of
MediaWiki not suck.

> A great place to start would be the SMW Bundle:
>   http://www.mediawiki.org/wiki/Semantic_Bundle

Oh man, if I could apt-get that my life would be way easier. (Looking
into the future when there's a current, maintained, not-insane
MediaWiki in Debian/Ubuntu.)

- d.
Derric Atzrott | 28 Sep 18:15 2012

Re: Dependency management, MediaWiki and modularity

>> I do agree with David Gerard's assessment, though.  We need to make sure
>> that whatever we use is going to work with package management tools that
>> Debian and Redhat and the like already use.
>
>The other reason is, of course, making the distro versions of
>MediaWiki not suck.
>
>> A great place to start would be the SMW Bundle:
>>   http://www.mediawiki.org/wiki/Semantic_Bundle
>
>Oh man, if I could apt-get that my life would be way easier. (Looking
>into the future when there's a current, maintained, not-insane
>MediaWiki in Debian/Ubuntu.)

With the exception of phpMyAdmin, I don't think I've ever seen a piece of PHP
software that you could really just apt-get and have easily installed.  So this
is definitely a worthy goal to pursue.

I too would love it if I could set up a simple Wiki on an Ubuntu/Debian box by
typing "apt-get install mediawiki mediawiki-extension-XYZ
mediawiki-extension-ZYX".

Thank you,
Derric Atzrott
Mark A. Hershberger | 28 Sep 18:32 2012

Re: Dependency management, MediaWiki and modularity

On 09/28/2012 12:15 PM, Derric Atzrott wrote:

> With the exception of phpMyAdmin, I don't think I've ever seen a piece of PHP
> software that you could really just apt-get and have easily installed.  So this
> is definitely a worthy goal to pursue.
> 
> I too would love it if I could set up a simple Wiki on an Ubuntu/Debian box by
> typing "apt-get install mediawiki mediawiki-extension-XYZ
> mediawiki-extension-ZYX".

Platonides has been doing this work with the Debian developers on the
mediawiki-distributors list.

We still need someone to work with the RedHat/Fedora folks.  I initially
said I would but I haven't had as much time to commit to that as I
thought I would.  If someone is familiar with RPMs, this is a great
place to help MediaWiki.

Mark.

--

-- 
http://hexmode.com/

Necessitous men are not, truly speaking, free men.
 -- Vernon v Bethell (1762), quoted by FDR's Second Bill of Rights
David Gerard | 28 Sep 16:10 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On 28 September 2012 02:47, Mark A. Hershberger <mah <at> everybody.org> wrote:

> The problem, though, is that there is no way to install, use, or update
> extensions apart from doing it by hand.  Requiring the installation of
> multiple modules by hand isn't going to lead to a thriving, modular
> ecosystem.  We need a dependency manager.

After the ones about sending email and Common Lisp, we can add:

"Every app also expands until it contains a sketchy rewrite of apt-get."

c.f. Perl, PHP, Ruby, Python, WordPress ...

One thing to possibly think about: compatibility of any new system
with Linux distro packaging mechanisms, like apt-get and yum. The less
distro maintainers have to mess with MediaWiki the better.

- d.
Derric Atzrott | 28 Sep 16:23 2012

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

>After the ones about sending email and Common Lisp, we can add:
>
>"Every app also expands until it contains a sketchy rewrite of apt-get."
>
>c.f. Perl, PHP, Ruby, Python, WordPress ...
>
>One thing to possibly think about: compatibility of any new system
>with Linux distro packaging mechanisms, like apt-get and yum. The less
>distro maintainers have to mess with MediaWiki the better.

Wanted to send this to you directly, since it is off topic.

Where is that quote from?  It is so incredibly true.

Thank you,
Derric Atzrott
Derric Atzrott | 28 Sep 16:25 2012

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

>After the ones about sending email and Common Lisp, we can add:
>
>"Every app also expands until it contains a sketchy rewrite of apt-get."
>
>c.f. Perl, PHP, Ruby, Python, WordPress ...
>
>One thing to possibly think about: compatibility of any new system
>with Linux distro packaging mechanisms, like apt-get and yum. The less
>distro maintainers have to mess with MediaWiki the better.
>
>Wanted to send this to you directly, since it is off topic.
>
>Where is that quote from?  It is so incredibly true.

Sorry all. I meant to send that to just him.

Thank you,
Derric Atzrott
David Gerard | 28 Sep 16:24 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

On 28 September 2012 15:25, Derric Atzrott <datzrott <at> alizeepathology.com> wrote:

>>Where is that quote from?  It is so incredibly true.

> Sorry all. I meant to send that to just him.

And then I failed to notice I was sending to the list too.

apt-get purge clue

- d.
David Gerard | 28 Sep 16:23 2012
Picon

Re: Dependency management, MediaWiki and modularity (was Re: New extension: Diff)

I made it up at work a few weeks ago :-) We were discussing the
questionable maintainability of apps and languages that insist on
handrolling their own dependency management, particularly when they do
it in a way that doesn't match how distros do it.

On 28 September 2012 15:23, Derric Atzrott <datzrott <at> alizeepathology.com> wrote:
>>After the ones about sending email and Common Lisp, we can add:
>>
>>"Every app also expands until it contains a sketchy rewrite of apt-get."
>>
>>c.f. Perl, PHP, Ruby, Python, WordPress ...
>>
>>One thing to possibly think about: compatibility of any new system
>>with Linux distro packaging mechanisms, like apt-get and yum. The less
>>distro maintainers have to mess with MediaWiki the better.
>
> Wanted to send this to you directly, since it is off topic.
>
> Where is that quote from?  It is so incredibly true.
>
> Thank you,
> Derric Atzrott
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l <at> lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
(Continue reading)

Mark A. Hershberger | 25 Oct 12:23 2012

Composer use in MediaWiki

I saw (via Siebrand) this tweet Tuesday from Nils Adermann of Composer fame:

  Fusing #PHP communities: Promising discussions on code reuse in
  #MediaWiki through #composerphp this afternoon at  <at> wikimedia, thanks
   <at> robla!   https://twitter.com/naderman/status/260918497276731392

What is the status on this discussion?  Are we planning to use Composer
in the future?  This sounds really exciting!

Mark.

On 09/27/2012 09:47 PM, Mark A. Hershberger wrote:
> Thankfully, I think there is already a dependency manager that we can
> build on.
>
> I'm talking about Composer (http://getcomposer.org/).
>
> Of course, MediaWiki isn't aware of this dependency manager and so
> MediaWiki's extensions aren't either.  I've only looked at it briefly,
> but it appears that adding support wouldn't be difficult at all -- it
> would just mean adding a file to the git repository.
>
> What do you think?
>
> Mark.
>
Tyler Romeo | 25 Oct 16:51 2012
Picon

Re: Composer use in MediaWiki

Well I think we agreed before somewhere that we should not use Composer for
installation of MW extensions, and that MW is in dire need of its own
extension management code.
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo <at> gmail.com

On Thu, Oct 25, 2012 at 6:23 AM, Mark A. Hershberger <mah <at> everybody.org>wrote:

> I saw (via Siebrand) this tweet Tuesday from Nils Adermann of Composer
> fame:
>
>   Fusing #PHP communities: Promising discussions on code reuse in
>   #MediaWiki through #composerphp this afternoon at  <at> wikimedia, thanks
>    <at> robla!   https://twitter.com/naderman/status/260918497276731392
>
> What is the status on this discussion?  Are we planning to use Composer
> in the future?  This sounds really exciting!
>
> Mark.
>
> On 09/27/2012 09:47 PM, Mark A. Hershberger wrote:
> > Thankfully, I think there is already a dependency manager that we can
> > build on.
> >
> > I'm talking about Composer (http://getcomposer.org/).
> >
> > Of course, MediaWiki isn't aware of this dependency manager and so
(Continue reading)

Mark A. Hershberger | 25 Oct 16:58 2012

Re: Composer use in MediaWiki

On 10/25/2012 10:51 AM, Tyler Romeo wrote:
> Well I think we agreed before somewhere that we should not use Composer for
> installation of MW extensions, and that MW is in dire need of its own
> extension management code.

I do remember that you said that, but I don't remember that being the
consensus.  If there is real traction on something that is MW-specific,
then I'm all for it, but this is something that works *now* as Antoine
has demonstrated.

From the tweet, it sounds like Robla reached out to Nils Adermann.  If
that is what happened, then I'm very interested to hear more from the
WMF side.

Mark.

--

-- 
http://hexmode.com/

Any time you have "one overriding idea", and push your idea as a
    superior ideology, you're going to be wrong. ... The fact is,
    reality is complicated -- Linus Torvalds <http://hexm.de/mc>
Chad | 25 Oct 17:02 2012
Picon

Re: Composer use in MediaWiki

On Thu, Oct 25, 2012 at 10:58 AM, Mark A. Hershberger <mah <at> everybody.org> wrote:
> On 10/25/2012 10:51 AM, Tyler Romeo wrote:
>> Well I think we agreed before somewhere that we should not use Composer for
>> installation of MW extensions, and that MW is in dire need of its own
>> extension management code.
>
> I do remember that you said that, but I don't remember that being the
> consensus.  If there is real traction on something that is MW-specific,
> then I'm all for it, but this is something that works *now* as Antoine
> has demonstrated.
>
> From the tweet, it sounds like Robla reached out to Nils Adermann.  If
> that is what happened, then I'm very interested to hear more from the
> WMF side.
>

Indeed. We've tossed it around for a couple of things but never really
looked at it in-depth. I loathe wheel reinvention, so if we can make use
of all or parts of other people's work, then I see no reason not to.

-Chad
Tyler Romeo | 25 Oct 17:04 2012
Picon

Re: Composer use in MediaWiki

>
> I do remember that you said that, but I don't remember that being the
> consensus.  If there is real traction on something that is MW-specific,
> then I'm all for it, but this is something that works *now* as Antoine
> has demonstrated.

It was Daniel Friesen's suggestion, and then myself and a few others agreed
with him.
Here's the original thread:
http://lists.wikimedia.org/pipermail/wikitech-l/2012-September/063503.html
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerromeo <at> gmail.com

On Thu, Oct 25, 2012 at 10:58 AM, Mark A. Hershberger <mah <at> everybody.org>wrote:

> On 10/25/2012 10:51 AM, Tyler Romeo wrote:
> > Well I think we agreed before somewhere that we should not use Composer
> for
> > installation of MW extensions, and that MW is in dire need of its own
> > extension management code.
>
> I do remember that you said that, but I don't remember that being the
> consensus.  If there is real traction on something that is MW-specific,
> then I'm all for it, but this is something that works *now* as Antoine
> has demonstrated.
>
> From the tweet, it sounds like Robla reached out to Nils Adermann.  If
(Continue reading)

Mark A. Hershberger | 25 Oct 17:50 2012

Re: Composer use in MediaWiki

On 10/25/2012 11:04 AM, Tyler Romeo wrote:
> It was Daniel Friesen's suggestion, and then myself and a few others agreed
> with him.

Like I said, if you guys come up with something MW-specific, I would
support it.  I think it should be demonstrably better than what Antoine
has done with Composer, though.

Mark.
Antoine Musso | 25 Oct 18:17 2012
Picon

Re: Composer use in MediaWiki

Le 25/10/12 16:51, Tyler Romeo a écrit :
> Well I think we agreed before somewhere that we should not use Composer for
> installation of MW extensions, and that MW is in dire need of its own
> extension management code.

I myself dislike us constantly reinventing the wheel. I would really
prefer we reuse an existing package manager unless it can not fit our
needs at all or is so badly designed that we can not extends it.

--

-- 
Antoine "hashar" Musso
Rob Lanphier | 25 Oct 19:15 2012
Picon

Re: Composer use in MediaWiki

On Thu, Oct 25, 2012 at 3:23 AM, Mark A. Hershberger <mah <at> everybody.org> wrote:
> I saw (via Siebrand) this tweet Tuesday from Nils Adermann of Composer fame:
>
>   Fusing #PHP communities: Promising discussions on code reuse in
>   #MediaWiki through #composerphp this afternoon at  <at> wikimedia, thanks
>    <at> robla!   https://twitter.com/naderman/status/260918497276731392
>
> What is the status on this discussion?  Are we planning to use Composer
> in the future?  This sounds really exciting!

We had an impromptu conversation with Nils since he's currently
staying very close to the SF office this week.  Had we not run into
scheduling issues, we might have had him join our weekly tech chat so
that remote participants.  We plan to have him in a tech chat in the
near future.

No decisions were made.  The discussion we had was really an
educational one for Chris Steipp, Aaron Schulz and myself.  Nils
demonstrated the main features of Composer to us, and then the
conversation wandered on to Symfony.

Symfony, incidentally, has apparently been through a major rewrite in
the not-too-distant past, and now focuses on providing a suite of
reusable standalone components.  Apparently, several older projects
(phpBB, Joomla Platform, Drupal) are starting to incorporate Symfony
components in their work.

Some of what we were doing was a brief redux of the conversation many
of us had at the GSoC Mentors Summit.  Very rough notes here:
http://gsoc-wiki.osuosl.org/index.php/PHP
(Continue reading)


Gmane