One thing that concerns me about the proposed composer setup, that I haven't mentioned yet, is the nesting of the project hierarchy, with mediawiki/core/vendor inside mediawiki/core.
You know that we have mediawiki/extensions instead of mediawiki/core/extensions -- that makes it easy to check out all Gerrit repos in the natural directory hierarchy and to still have a clean $IP/extensions which you can use for installer testing or whatever.
I wonder if a similar solution is possible with vendor -- could we have mediawiki/vendor instead of mediawiki/core/vendor? Then it would be possible to play around with dropping things into $IP/vendor while still having the "vendor" git repo checked out in a sensible location, available for editing.
-- Tim Starling
On 11/06/14 22:26, Tim Starling wrote:
One thing that concerns me about the proposed composer setup, that I haven't mentioned yet, is the nesting of the project hierarchy, with mediawiki/core/vendor inside mediawiki/core.
You know that we have mediawiki/extensions instead of mediawiki/core/extensions -- that makes it easy to check out all Gerrit repos in the natural directory hierarchy and to still have a clean $IP/extensions which you can use for installer testing or whatever.
I wonder if a similar solution is possible with vendor -- could we have mediawiki/vendor instead of mediawiki/core/vendor? Then it would be possible to play around with dropping things into $IP/vendor while still having the "vendor" git repo checked out in a sensible location, available for editing.
-- Tim Starling
Actually, I like the sound of this. The extensions thing is sane (well, relatively) and useful. This would also perhaps be sane.
Hopefully we won't wind up with an explosion of these pocket repositories down the road, though, especially necessary ones... technically none of them are actually necessary currently, and I don't think we want core to eventually just be replaced by a meta repository of a whole bunch of component repositories that then have all their own component dealies and fish and squid and a bunch of goats scattered throughout?
Or... something.
-I
On Wed, Jun 11, 2014 at 7:40 PM, Isarra Yos zhorishna@gmail.com wrote:
and I don't think we want core to eventually just be replaced by a meta repository of a whole bunch of component repositories that then have all their own component dealies and fish and squid and a bunch of goats scattered throughout?
There are some who want to go further and have core just call various myriad services running as separate processes to do all the work. Like a Parsoid for every piece.
I actually think that Composer-installed stuff should be under $IP/includes as that's where most code should be.
On Wed, Jun 11, 2014 at 3:26 PM, Tim Starling tstarling@wikimedia.org wrote:
One thing that concerns me about the proposed composer setup, that I haven't mentioned yet, is the nesting of the project hierarchy, with mediawiki/core/vendor inside mediawiki/core.
You know that we have mediawiki/extensions instead of mediawiki/core/extensions -- that makes it easy to check out all Gerrit repos in the natural directory hierarchy and to still have a clean $IP/extensions which you can use for installer testing or whatever.
I wonder if a similar solution is possible with vendor -- could we have mediawiki/vendor instead of mediawiki/core/vendor? Then it would be possible to play around with dropping things into $IP/vendor while still having the "vendor" git repo checked out in a sensible location, available for editing.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 12/06/2014 02:40, Max Semenik a écrit :
I actually think that Composer-installed stuff should be under $IP/includes as that's where most code should be.
/includes/ is for our code
/includes/libs/ being an exception and holding some simple third parties libraries. That was introduced by http://mediawiki.org/wiki/Special:Code/MediaWiki/71763
Composer default to install packages in /vendor/ and we should stick to it to be aligned with the rest of the world.
wikitech-l@lists.wikimedia.org