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