Talk:Requests for comment/pywikibot 2.0 packaging

no library i18n
I think it is easiest if we remove the use of i18n from pagegenerators for 2.0, and design i18n into the next major release of the library. John Vandenberg (talk) 09:10, 29 November 2014 (UTC)

two packages
I think the simplest approach for 2.0 is to maintain two packages: 'pywikibot' (the library) and 'wikimedia-pywikibot' which includes the scripts (as pywikibot.scripts) and regularly updated family classes. Labs and wikimedia home-bot operators would install 'wikimedia-pywikibot', but non-WMF users would install 'pywikibot'.

Then we can plan to remove the worst of the family file issues by 2.1, meaning we only have the 'scripts' problem to worry about, and we have some time to resolve that properly. John Vandenberg (talk) 09:10, 29 November 2014 (UTC)

separately packaged wikimedia family files
I've been playing with packaging the wikimedia family files separately, and it is feasible. My first attempt requires intrusive changes to the bootstrap / config code, as the list of valid families is needed to validate the families used in the config (e.g. config.usernames), and a separate package needs to be able to 'import pywikibot' (which in turn loads config), causing a cyclic dependency between library and families package. But it is doable, and could be made much less intrusive. John Vandenberg (talk) 09:10, 29 November 2014 (UTC)
 * That would be my suggestion too. So everytime we need to update the family files we could just publish a new version of that. Also this would give us a chance to phase that out (slowly of course) and as soon as we don't need family files anymore (at least no default) users could just use the “main package”. Separating it could be a problem of course. — xZise &#91;talk&#93; 11:05, 29 November 2014 (UTC)
 * If we're going to have separate packages, we need a simple way for users to update.
 * The 'easy' solution is to have a 'wikimedia-pywikibot' package, which only exists to depend/install the other required packages? But that means releasing two packages any time one package needs to be updated.  More release work, though it could be automated, it is still more chance of mistakes being made. John Vandenberg (talk) 11:54, 29 November 2014 (UTC)
 * But the family files are not that often changed and just because pywikibot is updated, we don't also need to update the pywikibot-families or whatever this is going to be, especially if there were no changes made to the family itself. Isn't the question how we are going to get family related changes as fast as possible to the users, and this would be a solution.
 * The other of course would be to have that in the pywikibot package itself as I don't think that we need to fix those files that often. If you look in the families folder all files are almost at least a month old. And the more recent changes were not specific to the family file but are related to changing pywikibot itself, so we would have to release a new pywikibot version anyway. Changes like https://github.com/wikimedia/pywikibot-core/commit/ff69b61805ada9a60995fe3d061c033822f71962 could be delayed until a next release of pywikibot.
 * Also we don't want to break other people's scripts so we usually don't break anything so if we apply changes to pywikibot which would affect the families, those should work anyway as we won't break it. But I'm no expert about how packaging works so maybe it's not that easy to advance the pywikibot version without updating the repositories of pywikibot-families. — xZise &#91;talk&#93; 17:31, 29 November 2014 (UTC)