I have a bunch of breaking changes I'd like to make to the framework's
API; some of them are already in Gerrit ([1]
https://gerrit.wikimedia.org/r/178579, [2]
https://gerrit.wikimedia.org/r/178647).
John Vandenberg said they can be merged after the 2.0 release, but I
don't see a schedule yet.
Il 26/02/2015 22:31, John Mark Vandenberg ha scritto:
We need a wiki page which explains the current combat v core situation
suitable for new users.
Pun intended?
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
Hi! There appears to be a cooked script to do exactly that:
imagetransfer.py
https://www.mediawiki.org/wiki/Manual:Pywikibot/imagetransfer.py (I've
never used it though)
Il 25/02/2015 18:52, Brenton Horne ha scritto:
Hi,
About a month ago I transferred from a Wikia wiki
Il 24/02/2015 21:56, John ha scritto:
OK, First delete core. You dont need both.
Delete compat instead! Core is the future.
Then run:
generate_family_file.py http://localhost/mediawiki local
Follow that up with generate_user_files.py and then select local
If you have further needs please
.
When Trying to help new users I dont want to deal with the instability
and problems core still has. Ricordisamoa, Im not going to change your
option on this nor do I wish to debate it, since you are a relatively
new developer to pywiki, but Ive been using it for 10 years and I know
what works
Il 15/01/2015 17:26, Fabian Neundorf ha scritto:
Is there a styleguide or was there a discussion already, because I
think it would be good to have at least some set of rules. Some are
already handled by flake8 so jenkins will prevent that some style
guides are broken but there is for example:
This may sound stupid, but... why can't jobs be run by patch submitters?
Il 15/01/2015 11:44, Antoine Musso ha scritto:
Hello,
Yesterday I have restricted the tox Jenkins jobs to only be run by
whitelisted person. That is rather inconvenient :-(
To whitelist a person, its Gerrit email
pywikibot/core has a 'python3' branch which has been last updated in
October 2013.
Since the 'master' branch supports py3k fairly well now, it looks like
the old branch should be deleted.
Thoughts?
___
Pywikipedia-l mailing list
FYI
https://github.com/GreenSteam/pep257/pull/91
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
Thanks!
Il 08/01/2015 17:26, Merlijn van Deen ha scritto:
Done.
On 8 January 2015 at 16:20, Ricordisamoa ricordisa...@openmailbox.org wrote:
pywikibot/core has a 'python3' branch which has been last updated in October
2013.
Since the 'master' branch supports py3k fairly well now, it looks
Il 03/01/2015 09:56, John Mark Vandenberg ha scritto:
Thanks.
Which GCC is your CPython compiled for? Also GCC 4.9.0 ?
GCC 4.9.1
What would be especially useful is if we can determine which methods
are performing vastly slower on CPython vs PyPy for that workload.
What do you think of the new (proposed) logo? I think it's great, though
it uses WMF colors while Pywikibot aims to work with every MediaWiki
installation.
Il 14/12/2014 08:48, Ricordisamoa ha scritto:
About
http://gallaecio.deviantart.com/art/Pywikibot-Alternative-Logo-475995567
and
https
Xqt made gerrit:178796 https://gerrit.wikimedia.org/r/178796/ not
depend on gerrit:179591 https://gerrit.wikimedia.org/r/179591/ anymore.
The latter should be merged, or the former should be reverted, because
of failing tests
https://travis-ci.org/wikimedia/pywikibot-core/jobs/44055432.
I
in
separate wikis for those who are able to use bots but have
difficulties with English. (IMO)
2014-12-14 8:31 GMT+01:00 Ricordisamoa ricordisa...@openmailbox.org
mailto:ricordisa...@openmailbox.org:
I found some documentation about PWB on Wikiversity and Wikibooks:
https
About
http://gallaecio.deviantart.com/art/Pywikibot-Alternative-Logo-475995567
and
https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Python_logos:
can we get the new logo in?
___
Pywikipedia-l mailing list
We should work on bringing and keeping the user manual up-to-date.
When pages are stable, they should be marked for translation (including
code samples).
Also, why not to create a 'non-technical hub' at
https://www.mediawiki.org/wiki/Pywikibot (to which most related external
sites should
Just found this http://pybot.wikia.com :-)
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
m:International Pywiki Project
https://meta.wikimedia.org/wiki/International_Pywiki_Project was
launched by Bináris in 2012, but seems dead presently.
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
Since TranslateWiki doesn't seem to be the appropriate place for
localization dictionaries used in scripts, why not to create a 'L10n'
folder or a pywikibot/L10n repository (cf. pywikibot/i18n) to hold them?
___
Pywikipedia-l mailing list
Il 07/08/2014 10:59, Jan Dudík ha scritto:
recently I got few mail per day, but last few days there are 30 or
more mails every day.
Maybe there is now higher activity with solving bugs?
JAnD
Simply, I came back ;-)
___
Pywikipedia-l mailing list
py2.6 tests on Travis-CI are now allowed to fail, meaning that we are,
actually, supporting only 2.7+.
I renew my proposal to *drop* support for py2.6 at all.
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
Il 07/08/2014 23:48, John Mark Vandenberg ha scritto:
On Fri, Aug 8, 2014 at 4:37 AM, Ricordisamoa
ricordisa...@openmailbox.org wrote:
py2.6 tests on Travis-CI are now allowed to fail, meaning that we are,
actually, supporting only 2.7+.
I would prefer to say that we've made py 2.6 a second
Il 06/08/2014 21:47, John Mark Vandenberg ha scritto:
On Wed, Aug 6, 2014 at 11:59 PM, Ricordisamoa
ricordisa...@openmailbox.org wrote:
Il 06/08/2014 12:56, Merlijn van Deen ha scritto:
Siebrand confirms: we should change it in code, and tw.net will pick it up.
Merlijn
Thanks a lot! Filed
It has been reported
https://it.wikipedia.org/wiki/Speciale:Diff/67448044 to me that core's
welcome.py doesn't stop with the '-break' option enabled.
Unfortunately, I have no past experience with it. Does it work for you?
___
Pywikipedia-l mailing
Il 06/08/2014 12:56, Merlijn van Deen ha scritto:
Siebrand confirms: we should change it in code, and tw.net
http://tw.net will pick it up.
Merlijn
Thanks a lot! Filed gerrit:152138
https://gerrit.wikimedia.org/r/152138/ and gerrit:152139
https://gerrit.wikimedia.org/r/152139/.
I hereby propose to start a Bugzilla+Gerrit Task Force to reduce network
usage by the framework and to enhance our low-level code.
I hardly ever inspect files like data/api.py, but I see that even the
simplest queries get submitted as generators or with the 'userinfo'
property attached.
I've cleaned it up
https://www.mediawiki.org/w/index.php?diff=1089478oldid=788068.
Please feel free to make additional improvements.
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
The format should be changed to older than $1 to avoid i18n issues.
Should the edit happen on TranslateWiki.net, or in our i18n files directly?
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
Currently, the Version field of our bugs can only be set to one of
compat (1.0), core (2.0) or unspecified.
Why not to create a new both option to explicitly indicate that the
bug is valid for both versions?
So, unspecified would only mean that the bug has not been tested on
both versions.
botwiki:Template:Script http://botwiki.sno.cc/wiki/Template:Script
lists some old PWB scripts.
it:Utente:BimBot/Scripts
https://it.wikipedia.org/wiki/Utente:BimBot/Scripts contains some others.
They could still be useful, even if they'd be rewritten almost completely.
How can I request new components for the product Pywikibot in Bugzilla?
They would be extremely useful, especially for very used scripts like
textlib.py.
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
Il 24/07/2014 17:39, Thehelpfulone ha scritto:
Please can you make a request in Bugzilla, create a new bug under
Wikimedia - Bugzilla component so that the request to add components
is publicly logged? Let me know when you’ve done so and I’ll add the
component(s) for you.
--
Thehelpfulone
A notice about the move to Bugzilla has been added, but many bugs still
show up as 'open'.
Is this expected/wanted?
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
Il 23/07/2014 18:46, Gerard Meijssen ha scritto:
Hoi,
Maybe a stupid question, but given that WMF is moving away from
Bugzilla, does it make sense for pywikibot to move to Bugzilla?
Thanks,
GerardM
Pywikibot moved to Gerrit+Bugzilla many months ago!
Can we establish a guideline on when to mark our bugs as VERIFIED FIXED?
Is that status useful?
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
Il 21/07/2014 23:47, Legoktm ha scritto:
On 7/19/14, 7:56 AM, Ricordisamoa wrote:
It seems from bugzilla:64850
https://bugzilla.wikimedia.org/show_bug.cgi?id=64850 and gerrit:131331
https://gerrit.wikimedia.org/r/131331/ that we're going to split the
CommonsDelinker out of our codebase.
Can I
If pywikibot/wiktionary is reasonably useful for the core branch, then
supporting 'compat' is less important.
If /wiktionary could take advantage of some features of 'core' which
'compat' does not have,
IMHO compat should be left with its old version and /wiktionary be added
as submodule in
It seems from bugzilla:64850
https://bugzilla.wikimedia.org/show_bug.cgi?id=64850 and gerrit:131331
https://gerrit.wikimedia.org/r/131331/ that we're going to split the
CommonsDelinker out of our codebase.
Can I request a new repository? What about the name?
to me.
Il 18/07/2014 13:58, John Mark Vandenberg ha scritto:
On Fri, Jul 18, 2014 at 9:26 PM, Ricordisamoa
ricordisa...@openmailbox.org wrote:
Many of our scripts have copyright notices at the top like this
(category.py):
# (C) Rob W.W. Hooft, 2004
and then:
# (C) Pywikibot team, 2008-2013
even
Hey guys, we've got a huge backlog.
One of the main requirements to comply with mw:API:Client code/Gold
standard https://www.mediawiki.org/wiki/API:Client_code/Gold_standard
is the speed of code-review processes.
___
Pywikipedia-l mailing list
You must see this! https://github.com/GreenSteam/pep257
Just run it on our codebase, it gives thousands of errors...
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
I love the GPL /per se/, but I hate license conflicts. IMHO we should
send an email to each author.
Il 09/06/2014 11:28, xqt ha scritto:
Hey folks,
Sorry about that. I'd happily relicense the original code under whatever is
convenient for you.
If anyone contributed to the file in the
Thank you, but I think we will keep our dependency on mwparserfromhell.
Even though it has issues on Windows, it is way more powerful and
reliable than any other wikicode parser in Python.
And it does not only parse nested templates, but also wikilinks,
external links and HTML tags.
Il
That change was introduced by Legoktm in gerrit:80328
https://gerrit.wikimedia.org/r/80328/, which caused some tests to
fail, and thus was reverted by Merlijn van Deen in gerrit:80765
https://gerrit.wikimedia.org/r/80765/.
It implemented a Claim._buildMainSnak() method and some serialization
I'm in the process of converting several scripts to use the framework's
generic Bot class (gerrit:137334
https://gerrit.wikimedia.org/r/137334/, gerrit:137346
https://gerrit.wikimedia.org/r/137346/, gerrit:137354
https://gerrit.wikimedia.org/r/137354/, gerrit:138219
In addition to making your own patches, you can review others' on Gerrit
https://gerrit.wikimedia.org/r/#/q/status:open+project:pywikibot/core,n,z.
I saw you have an account there, and since Google also uses it, you are
supposed to know how to work with it. ;-)
Il 06/06/2014 08:34, Travis
It seems to me that the current trend is to use the same attribute as
both a getter and a setter, e.g. Page.text.
Is this true? Should we convert Claim.getTarget() and .setTarget() to
just target (which is already used internally)?
___
Pywikipedia-l
I found this in the source code of scripts/reflinks.py:
Distributed under the terms of the GPL
This seems to be the single case in the whole repository. Is it
compatible with our license conventions?
It even doesn't have a full GNU-style license header.
I am not sure it's always better to use site.code instead of site.lang.
If TranslateWiki uses language codes, 'be-tarask' should be used instead
of 'be-x-old', etc.
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
https://travis-ci.org/wikimedia/pywikibot-core/jobs/26754246
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
No difference in front-end, because __init__.py would be changed from
from .page import Page, ImagePage, Category, Link, User, ItemPage,
PropertyPage, Claim
into
from .page import Page, ImagePage, Category, Link, User
from .wikibase import ItemPage, PropertyPage, Claim, WbTime, WbQuantity
I'm
Done as bug 65987 https://bugzilla.wikimedia.org/show_bug.cgi?id=65987
Il 01/06/2014 09:12, Amir Ladsgroup ha scritto:
Sounds like a good idea, Go ahead :)
Best
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
mw:Manual talk:Pywikibot/Development guideline
https://www.mediawiki.org/wiki/Manual_talk:Pywikibot/Development_guideline
I've added two questions about whether to use single or double quotes,
and old or new-style string formatting.
___
Pywikipedia-l
gerrit:135405 https://gerrit.wikimedia.org/r/135405/ is a very simple
change. Please review it.
Otherwise, I'd have to rework some parts of 125575
https://gerrit.wikimedia.org/r/125575/.
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
Does anyone know how to print a deprecation warning every time someone
runs 'compat'?
I have tried putting it in wikipedia.py, but with no results.
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
Some of the most interesting features are in
w:Wikipedia:AutoWikiBrowser/General fixes
https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/General_fixes
while most of the utility code is in AWB/WikiFunctions/
http://sourceforge.net/p/autowikibrowser/code/HEAD/tree/AWB/WikiFunctions/
(e.g.
It is not a matter of personal tastes, but of actual functionality and
progress.
Anyway never mind, no consensus → no warning ;-)
Il 01/06/2014 22:27, Bináris ha scritto:
Fortunately.
For God's sake, please, don't even try to dream of that.
Leave people to choose without feeling guilty.
I will
OMG... such issues must be discussed and resolved, no matter if compat
is to be deprecated or not.
Il 01/06/2014 23:44, John ha scritto:
Im the same way, Ive tried setting up core half a dozen times in the
last 18 months and each time within 5 minutes Ive run into critical
issues that make
I propose to create a tracking bug for all features present in
AutoWikiBrowser but not in our 'core' (e.g. gerrit:118795
https://gerrit.wikimedia.org/r/118795).
Even if the user targets of the two projects are different nowadays, as
different are their tasks, I think PWB is going to be the
Per gerrit:127467 https://gerrit.wikimedia.org/r/127467/ and bug
55882#c5 https://bugzilla.wikimedia.org/show_bug.cgi?id=55882#c5, we
should add https://pypi.python.org/pypi/ordereddict as a requirement for
installing/using pywikibot.
Any volunteers for a patch?
Since gerrit:131263 https://gerrit.wikimedia.org/r/131263/ , it seems
to me that the excellent mwpfh is going to be used more and more
extensively within our framework.
Am I right? For example, the DuplicateReferences detection and fix in
reflinks.py could be brightly refactored without regular
How about creating a wikibase.py file in the pywikibot/ directory to
contain DataSite, WikibasePage, ItemPage, Claim, WbTime, WbQuantity, etc.?
___
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
62 matches
Mail list logo
