Talk:Requests for comment/Minimalistic MW API Client Lib Specification

Comments by BJorsch (Anomie)
I have no objection to someone doing this, or something like it. But I don't want to be expected to maintain it myself, not least because I'm not very familiar with Python. BJorsch (WMF) (talk) 16:57, 3 June 2015 (UTC)
 * Not a problem, I think we have plenty of python devs around. This lib should simply show "good practices" from the API-devs perspective, as described in the docs. --Yurik (talk) 16:59, 3 June 2015 (UTC)

token
Getting a token using different versions of the API involves three different API calls. See API:Token and API:Tokens (action) for two of them.

Would this API module handle all three versions? John Vandenberg (talk) 05:49, 4 June 2015 (UTC)

console logger?
Doesn't that make it more like a minimal bot framework than a client library? Also, did you consider mwclient? It's supposed to be quite minimal, and you'r welcome to join forces improving it if you like :) Danmichaelo (talk) 20:49, 4 June 2015 (UTC)


 * The example ConsoleLog looks like it is a very basic implementation of converting InfoObject's into messages shown to the user. It is useful for lazy programmers who are using this api layer directly in a quick hack, without using a proper client that would handle the InfoObject's properly.
 * I dont mind this layer having a utility functions for that purpose, but I do think this is bad approach. Callers should use logging.basicConfig if they want a basic console logger, and this new api layer should provide a utility function to accept a InfoObject and translate it into logging calls.  That promotes correct python usage, however that is an implementation detail.
 * mwclient is way too large for what Yuri & others are asking for. They expressly do not want a package that has a configuration file, with all the code to handle that.  They also do not want this layer implementing api calls (e.g.allpages, etc) except those explicitly included in this specification, e.g. login, token.
 * My limited understanding of their desires is that they also do not want this new api layer to do any site initialisation, or handling of backwards compatibility. (mwclient and pywikibot both do that, fetching siteinfo,userinfo,etc). I am still unclear about this part, as implementing 'token' has implications (see section above). John Vandenberg (talk) 09:21, 5 June 2015 (UTC)

Costs of maintenance
I don't think that this addresses real-world issues. I think that it is much more laborious to port a tool to use this library than to watch the API announcements and implement the (very few) breaking changes that occur from time to time.

In addition, while the current breaking change in continuation may be solvable by such a library, I assume most breaking changes will, well, break workflows.

This doesn't mean that there shouldn't be some responsibility on the part of WMF to only deploy when it is sure for example that Pywikibot doesn't break. With MediaWiki and Pywikibot both using Phabricator for task management and talk of setting up Pywikibot as a Jenkins test, this should be easily doable.

Also, it may be useful for Pywikibot to outfactor some functions. As others have pointed out, this should take into account the existing libraries in the field. --Tim&#160;Landscheidt 01:50, 5 June 2015 (UTC)


 * I tend to agree wrt Pywikibot. The Pywikibot folk at the Lyon meeting were more interested in documenting what 'core' looks like now to dispel some rather large myths about its unsuitability for some tasks, and continuing to lighten pywikibot of stuff inherited from before the MW API even existed, and/or move towards a more componentised system (i.e. the Family class).  Then we can have a better discussion about future architecture with all stakeholders having a common understanding about what 'Pywikibot' is.  A new API layer is not about preventing breakages in Pywikibot; we've already got enough testing occurring that we've prevented any API breakages hitting production 'core' bots in the last 12 months, and most of these API breakages have not been 'announced', and often they are unintentional.  Where we have a weakness is that we only run all tests on new checkins for pywikibot, which means API breakages may slip through if merges dont occur on a deploy days or people dont triage build breakages (which does happen when the builds are red for long periods).
 * However I do agree with user:Yurik and user:Halfak (WMF) that our ecosystem needs a reference implementation in Python, which would be useful for building new smallish tools, or building new clients or even libraries which provide a rich layer to a narrow part of the API. It may be that pywikibot functionality is moved into new libraries that use this new simple API, while the more complex parts of pywikibot continue to use its own API layer. John Vandenberg (talk) 09:48, 5 June 2015 (UTC)