Semanticmediawiki: "Auto-enable by composer ... agreed by all but SMW"
With reference to the following thread [0] and the statement "Auto-enable by composer probably isn't a good idea, this is agreed by all but SMW."
(Cindy) Couple of different aspects. Extensions dependent on MW Core version, i.e. Chameleon → Bootstrap → SCSS.
(Markus) Auto-enable by composer probably isn't a good idea, this is agreed by all but SMW.
@kghbln @hexmode I don't know what above comment entails or is trying to highlight but indicating that SMW has not agreed to it without clarifying that with the project or at least invite @kghbln to comment on such issues seems premature.
Does SMW in the above context refers to the extension or the community? In any event, while most SMW extensions are available and installed via Composer those are not auto-enabled, so any statement indicating otherwise is incorrect.
mwjames
All 2 comments
I suspect that the autoloading of the Validator and the ParserHooks extension are meant here.
Apart from that there are still semantic extensions which autoload though none of them was yet released officially. Probably a good occasion to actually convert them to extension registration and release them.
kghbln
on 16 May 2020
@mwjames sorry I missed this earlier.
This was part of a discussion that led to the Hybrid extension management RFC where I would really like to get your input. (In fact, I was coming here to file an issue on it and found this discussion.)
That RFC (and the #mwstake discussion) was the result of (some of) our frustration with the WMF stance which, up till now, has been "Don't use composer for extensions because of T467" where composer usage for extensions was previously discussed and dismissed.
As you know, many MW extension authors (including myself) have since embraced composer/packagist for installing extensions. To get past the stop energy of T467, we are working to create a new RFC and hope to have it discussed and eventually accepted by TechCom in the coming weeks. This is where your input would really be valuable.
Hopefully, this will help us foster relationships that lead to a more amicable co-existence between the core MW team and MW extension developers who work on extensions that are not used by the WMF.
hexmode
on 22 May 2020
Related issues
MvGulik
·
4Comments
alex-mashin
·
4Comments
Larivact
·
4Comments
JeroenDeDauw
·
3Comments
djoris
·
4Comments
Most helpful comment
@mwjames sorry I missed this earlier.
This was part of a discussion that led to the Hybrid extension management RFC where I would really like to get your input. (In fact, I was coming here to file an issue on it and found this discussion.)
That RFC (and the #mwstake discussion) was the result of (some of) our frustration with the WMF stance which, up till now, has been "Don't use composer for extensions because of T467" where composer usage for extensions was previously discussed and dismissed.
As you know, many MW extension authors (including myself) have since embraced composer/packagist for installing extensions. To get past the stop energy of T467, we are working to create a new RFC and hope to have it discussed and eventually accepted by TechCom in the coming weeks. This is where your input would really be valuable.
Hopefully, this will help us foster relationships that lead to a more amicable co-existence between the core MW team and MW extension developers who work on extensions that are not used by the WMF.