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. --
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@gmail.com
On Tue, Sep 25, 2012 at 6:50 AM, Jeroen De Dauw jeroendedauw@gmail.comwrote:
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2012/9/26 Tim Starling tstarling@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.
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.
There sure are other design choices that can be discussed. But the picture painted above was exaggerated, and I merely wanted to add some data to it.
Cheers, Denny
P.S.: terminology: "total lines of code" - lines in all code files, "physical lines of code" every line that has at least one non-comment or non-whitespace character. All numbers according to cloc.
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.
Although you find small things to nitpick over, I'm confident the overall design is sound. The Diff and DiffOps are following the composite pattern, which seems very much like the right choice to me. I would not mind being proven wrong or having other constructive discussion though.
"This is crap" is not constructive.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On Sep 25, 2012, at 7:54 PM, Tyler Romeo tylerromeo@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.
It goes at the cost of not having a standard, but I'm not sure a blanket "standard now, must use this" is what we want here, at least not until it has proven itself by being used over a long period of time by other extensions.
I mean, things don't have to be in core to be usable. Let it be an extension, let it grow. Extensions can perfectly depend on other extensions, there is no need to have it be in core, make your own decisions.
-- Krinkle
So unless other existing core functionality would need it, it doesn't make sense to include it.
This makes sense.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Wed, Sep 26, 2012 at 1:54 PM, Krinkle krinklemail@gmail.com wrote:
So unless other existing core functionality would need it, it doesn't make sense to include it.
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.
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@gmail.com
On Thu, Sep 27, 2012 at 9:47 PM, Mark A. Hershberger mah@everybody.orgwrote:
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.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, 27 Sep 2012 18:47:41 -0700, Mark A. Hershberger mah@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.
What do you think?
Mark.
We probably don't want to depend much on it.
Composer is really a tool for 3rd party library installation. And extensions aren't 3rd party libraries. Some issues with Composer in this regard: - Composer is a CLI library install tool. Depending on it will very likely get in the way of offering web based extension installation like just about every other major CMS. - Composer installs libraries in some arbitrary path (default vendor/, requires setting an ENV var or cli parameter to change) and politely asks you to use it's method of autoloading. This means the usual way of handling extensions with our own dir and require_once is out of the door. This probably won't work at all without a severe hack since we setup things in a php file we always require. It will also probably completely break extension asset loading. - Composer is not a full-fledged typical package manager. You cannot do something like `php composer.phar install mediawiki/Extension-ParserFunctions` you can only run `php composer.phar install` somewhere that a composer.json is defined. This means a few things: -- We can't make core depend on every extension so we will have to install with an individual extension as a base. -- This means you will have to install things by manually downloading some. And letting composer install others from within that extension. -- As a result of this Composer is going to try to install things in extensions/Foo/vendor/... this means our standard structure won't work. Worse Composer is not going to share things between extensions and probably won't work in the first place.
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@gmail.com
On Thu, Sep 27, 2012 at 10:32 PM, Daniel Friesen <daniel@nadir-seen-fire.com
wrote:
On Thu, 27 Sep 2012 18:47:41 -0700, Mark A. Hershberger mah@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.
What do you think?
Mark.
We probably don't want to depend much on it.
Composer is really a tool for 3rd party library installation. And extensions aren't 3rd party libraries. Some issues with Composer in this regard:
- Composer is a CLI library install tool. Depending on it will very likely
get in the way of offering web based extension installation like just about every other major CMS.
- Composer installs libraries in some arbitrary path (default vendor/,
requires setting an ENV var or cli parameter to change) and politely asks you to use it's method of autoloading. This means the usual way of handling extensions with our own dir and require_once is out of the door. This probably won't work at all without a severe hack since we setup things in a php file we always require. It will also probably completely break extension asset loading.
- Composer is not a full-fledged typical package manager. You cannot do
something like `php composer.phar install mediawiki/Extension-**ParserFunctions` you can only run `php composer.phar install` somewhere that a composer.json is defined. This means a few things: -- We can't make core depend on every extension so we will have to install with an individual extension as a base. -- This means you will have to install things by manually downloading some. And letting composer install others from within that extension. -- As a result of this Composer is going to try to install things in extensions/Foo/vendor/... this means our standard structure won't work. Worse Composer is not going to share things between extensions and probably won't work in the first place.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, 27 Sep 2012 21:10:40 -0700, Tyler Romeo tylerromeo@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 going truly modular some will argue otherwise.
To be done properly this is going to require tying into core to use and configure extensions in a different way. You also should not have to manually install an extension to get a user-friendly way to install extensions. So this should most definitely be part of core.
*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Thu, Sep 27, 2012 at 10:32 PM, Daniel Friesen <daniel@nadir-seen-fire.com
wrote:
On Thu, 27 Sep 2012 18:47:41 -0700, Mark A. Hershberger mah@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.
What do you think?
Mark.
We probably don't want to depend much on it.
Composer is really a tool for 3rd party library installation. And extensions aren't 3rd party libraries. Some issues with Composer in this regard:
- Composer is a CLI library install tool. Depending on it will very
likely get in the way of offering web based extension installation like just about every other major CMS.
- Composer installs libraries in some arbitrary path (default vendor/,
requires setting an ENV var or cli parameter to change) and politely asks you to use it's method of autoloading. This means the usual way of handling extensions with our own dir and require_once is out of the door. This probably won't work at all without a severe hack since we setup things in a php file we always require. It will also probably completely break extension asset loading.
- Composer is not a full-fledged typical package manager. You cannot do
something like `php composer.phar install mediawiki/Extension-**ParserFunctions` you can only run `php composer.phar install` somewhere that a composer.json is defined. This means a few things: -- We can't make core depend on every extension so we will have to install with an individual extension as a base. -- This means you will have to install things by manually downloading some. And letting composer install others from within that extension. -- As a result of this Composer is going to try to install things in extensions/Foo/vendor/... this means our standard structure won't work. Worse Composer is not going to share things between extensions and probably won't work in the first place.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Sep 28, 2012 at 1:11 AM, Daniel Friesen daniel@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
On Fri, 28 Sep 2012 04:52:40 -0700, Chad innocentkiller@gmail.com wrote:
On Fri, Sep 28, 2012 at 1:11 AM, Daniel Friesen daniel@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.
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 isn't the shiny diamond we think we want.
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.
To be done properly this is going to require tying into core to use and configure extensions in a different way. You also should not have to manually install an extension to get a user-friendly way to install extensions. So this should most definitely be part of core.
Perfect is the enemy of Good.
I agree with what you're saying, but I also want to point out that we can take something that *works*, use it now, and make it work *properly* later.
Mark "Friday's are for Aphorisms" Hershberger
On Fri, Sep 28, 2012 at 12:27 PM, Mark A. Hershberger mah@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
On 09/28/2012 12:29 PM, Chad wrote:
On Fri, Sep 28, 2012 at 12:27 PM, Mark A. Hershberger mah@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
(a little offtopic)
In my household we have a word for "sort of a plan but nothing definite and still in flux". It is a plin.
A plin turns into a plan once you've made a real commitment that has a cost. For example, a vacation plin turns into a plan when I buy airplane tickets.
I think the equivalent of an expensive commitment in our community is a public statement like "I will spend the next week working on $foo" or "I will deliver $bar by the end of the month" or even "I am actively working on $baz and will review new contributors' code in a timely fashion". That is more like a plan.
Plins are good! We need brainstorming and good intentions. But they are not really plans.
I agree with Mark about the danger of cookie-licking http://communitymgt.wikia.com/wiki/Cookie_Licking . BE BOLD (and loud) in overriding other people's plins with your own efforts!
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@gmail.com
On Fri, Sep 28, 2012 at 12:40 PM, Sumana Harihareswara < sumanah@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@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
(a little offtopic)
In my household we have a word for "sort of a plan but nothing definite and still in flux". It is a plin.
A plin turns into a plan once you've made a real commitment that has a cost. For example, a vacation plin turns into a plan when I buy airplane tickets.
I think the equivalent of an expensive commitment in our community is a public statement like "I will spend the next week working on $foo" or "I will deliver $bar by the end of the month" or even "I am actively working on $baz and will review new contributors' code in a timely fashion". That is more like a plan.
Plins are good! We need brainstorming and good intentions. But they are not really plans.
I agree with Mark about the danger of cookie-licking http://communitymgt.wikia.com/wiki/Cookie_Licking . BE BOLD (and loud) in overriding other people's plins with your own efforts!
-- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation
P.S. if you hate the idea of me using the word "plin" please contact me offlist to bikeshed a new term kthxbye :)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
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.
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.
Composer has the ability to generate an autoload file for all the dependencies and craft a general autoloader that your application can use to load everything.
I have submitted to upstream a patch that add some very basic support for MediaWiki installation:
https://github.com/composer/installers/pull/37 https://github.com/composer/installers/commit/43dd8edf22b3e9468b18db04c0b10a...
Which basically make it such that mediawiki/my-extension is installed under extensions/MyExtension (aka using CamelCase). It is not in Composer yet, you will have to run the latest head to take advantage of it.
I am assuming the autoloading stuff would need to be added to that mediawiki-extension Composer plugin. Someone would need to have a look at that :-]
If anyone has any interest in adding MediaWiki extension support in Composer, please reach them in their #composer IRC channel or via their mailing list. I am sure they will be glad to help us on that front.
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.
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 tarball with this bundle and it exposed some problems with the installer.
Mark.
On 28 September 2012 17:01, Mark A. Hershberger mah@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.
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
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.
On 28 September 2012 02:47, Mark A. Hershberger mah@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.
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
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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
On 28 September 2012 15:25, Derric Atzrott datzrott@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.
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 @wikimedia, thanks @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.
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@gmail.com
On Thu, Oct 25, 2012 at 6:23 AM, Mark A. Hershberger mah@everybody.orgwrote:
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 @wikimedia, thanks @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.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
On Thu, Oct 25, 2012 at 10:58 AM, Mark A. Hershberger mah@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
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@gmail.com
On Thu, Oct 25, 2012 at 10:58 AM, Mark A. Hershberger mah@everybody.orgwrote:
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.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
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.
On Thu, Oct 25, 2012 at 3:23 AM, Mark A. Hershberger mah@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 @wikimedia, thanks @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
Rob
wikitech-l@lists.wikimedia.org