I have created a table at http://www.botwiki.sno.cc/wiki/Rewrite/Porting_status to keep track of progress in porting files from the existing framework to the rewrite branch. So far it is quite incomplete (the first column is complete), but I intend to keep adding to it and encourage other developers to contribute. This can serve as a useful to-do list for those working on the project.
Russ
2009/4/9 Russell Blau russblau@imapmail.org
I have created a table at http://www.botwiki.sno.cc/wiki/Rewrite/Porting_status to keep track of progress in porting files from the existing framework to the rewrite branch. So far it is quite incomplete (the first column is complete), but I intend to keep adding to it and encourage other developers to contribute. This can serve as a useful to-do list for those working on the project.
Russ
Thanks for creating this list!
Should I understand this as "feel free to port any script to the new branch" ? =) Converting scripts is not the hardest part, I could start working seriously on this.
I am trying to split the scripts into categories, so that the scripts/ folder would not be cluttered by 100+ files, like it is the case in the current framework. I'd like to have several categories, such as "image", "interwiki", "references", to sort the scripts into subfolders. Any comments on this idea are welcome: finding a "perfect" categorization doesn't look straightforward :p
Also, I spent (again) some time looking at how to convert issues from the sourceforge tracker to another bug system, more specifically JIRA. It seems there is no satisfying way to convert those tickets at the moment, especially if we want to keep information such as the time when the ticket was opened, and last updated. For months now we've been saying, periodically, "sometime we should leave sourceforge". I'm starting to think that now is the time: we have created a "rewrite" category on sourceforge. Wouldn't it be interesting to simply open tickets related to rewrite core & rewrite-ported scripts on the JIRA on the toolserver? ( https://jira.toolserver.org/browse/PYWP )
When porting scripts, some issues of course are still independant of pywikibot implementation, but not creating new pywikibot issues on sourceforge would be great.
Nicolas Dumazet wrote:
Should I understand this as "feel free to port any script to the new branch" ? =) Converting scripts is not the hardest part, I could start working seriously on this.
Yes, absolutely -- be bold! :-)
I am trying to split the scripts into categories, so that the scripts/ folder would not be cluttered by 100+ files, like it is the case in the current framework. I'd like to have several categories, such as "image", "interwiki", "references", to sort the scripts into subfolders. Any comments on this idea are welcome: finding a "perfect" categorization doesn't look straightforward :p
Why not put suggested categories on the botwiki page? BTW, I'd really like to move scripts/ back under the pywikibot/ package; do you object?
Russ
2009/4/14 Russell Blau russblau@imapmail.org
Why not put suggested categories on the botwiki page?
Will do, when I'll find time for that.
BTW, I'd really like to move scripts/ back under the pywikibot/ package; do you object?
No strong objections. I'm just wondering why would you want to do that... :)
I personally liked the idea of clearly separating the core module used for mediawiki editing, and the "user" scripts we wrote from this core module. * The former is a set of primitives that any users are likely to need, the latter contains a lot of different scripts that are not necessary for creating a new mediawiki bot * From a developer perspective, it's very different to maintain core scripts or to modify user scripts. Someone with very little knowledge of the implementation of the core module can work to improve user scripts. A broken user script only stops this particular script from working; a broken core feature is likely to cause much more damage, etc...
But maybe that distinction is not important enough to get the user scripts out of the pywikibot bot module. As Merlijn (valhallasw) said, it might also be useful to be able to import pywikibot.script.foo.Particularclass from time to time.
Can we get your input Russell? =)
is pywikibot.script.foo.Particularclass always useful, stable and robust enough for other scripts to use? if it is, i think we can split it out and move it to somewhere like pywikibot.utils.foo.Particularclass
On 4/19/09, Nicolas Dumazet nicdumz@gmail.com wrote:
2009/4/14 Russell Blau russblau@imapmail.org
Why not put suggested categories on the botwiki page?
Will do, when I'll find time for that.
BTW, I'd really like to move scripts/ back under the pywikibot/ package; do you object?
No strong objections. I'm just wondering why would you want to do that... :)
I personally liked the idea of clearly separating the core module used for mediawiki editing, and the "user" scripts we wrote from this core module.
- The former is a set of primitives that any users are likely to need, the
latter contains a lot of different scripts that are not necessary for creating a new mediawiki bot
- From a developer perspective, it's very different to maintain core scripts
or to modify user scripts. Someone with very little knowledge of the implementation of the core module can work to improve user scripts. A broken user script only stops this particular script from working; a broken core feature is likely to cause much more damage, etc...
But maybe that distinction is not important enough to get the user scripts out of the pywikibot bot module. As Merlijn (valhallasw) said, it might also be useful to be able to import pywikibot.script.foo.Particularclass from time to time.
Can we get your input Russell? =)
-- Nicolas Dumazet — NicDumZ [ nɪk.d̪ymz ]
Nicolas Dumazet wrote:
2009/4/14 Russell Blau russblau@imapmail.org
BTW, I'd really like to move scripts/ back under the pywikibot/ package; do you object?
No strong objections. I'm just wondering why would you want to do that... :)
I personally liked the idea of clearly separating the core module used for mediawiki editing, and the "user" scripts we wrote from this core module.
- The former is a set of primitives that any users are likely
to need, the latter contains a lot of different scripts that are not necessary for creating a new mediawiki bot
- From a developer perspective, it's very different to
maintain core scripts or to modify user scripts. Someone with very little knowledge of the implementation of the core module can work to improve user scripts. A broken user script only stops this particular script from working; a broken core feature is likely to cause much more damage, etc...
But maybe that distinction is not important enough to get the user scripts out of the pywikibot bot module. As Merlijn (valhallasw) said, it might also be useful to be able to import pywikibot.script.foo.Particularclass from time to time.
Can we get your input Russell? =)
Two reasons. First, as per Merlijn, sometimes it is useful to import a component from one script into another script. (To answer Liangent, no, a lot of the time the scripts aren't written so that this is useful, but sometimes they are and it would be better authoring practice if we wrote more reusable components.)
Second, for distribution, it is cleaner to have all files relating to the framework distributed in a single package. We could address your concern by moving all the "core" modules into a pywikibot.core subpackage (that's how Django, for example, organizes their namespace).
Russ
django.contrib contains some modules which will be invoked by the framework users(developers), not the final users. i think what is in django.contrib is more reusable than scripts in pywikipedia. i think the latter are just originally written for final users(may be somebody who doesn't know coding)
On Sun, Apr 19, 2009 at 8:06 PM, Russell Blau russblau@imapmail.org wrote:
Nicolas Dumazet wrote:
2009/4/14 Russell Blau russblau@imapmail.org
BTW, I'd really like to move scripts/ back under the pywikibot/ package; doyou object?
No strong objections. I'm just wondering why would you want to do that... :)
I personally liked the idea of clearly separating the core module used for mediawiki editing, and the "user" scripts we wrote from this core module.
- The former is a set of primitives that any users are likely
to need, the latter contains a lot of different scripts that are not necessary for creating a new mediawiki bot
- From a developer perspective, it's very different to
maintain core scripts or to modify user scripts. Someone with very little knowledge of the implementation of the core module can work to improve user scripts. A broken user script only stops this particular script from working; a broken core feature is likely to cause much more damage, etc...
But maybe that distinction is not important enough to get the user scripts out of the pywikibot bot module. As Merlijn (valhallasw) said, it might also be useful to be able to import pywikibot.script.foo.Particularclass from time to time.
Can we get your input Russell? =)
Two reasons. First, as per Merlijn, sometimes it is useful to import a component from one script into another script. (To answer Liangent, no, a lot of the time the scripts aren't written so that this is useful, but sometimes they are and it would be better authoring practice if we wrote more reusable components.)
Second, for distribution, it is cleaner to have all files relating to the framework distributed in a single package. We could address your concern by moving all the "core" modules into a pywikibot.core subpackage (that's how Django, for example, organizes their namespace).
Russ
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
pywikipedia-l@lists.wikimedia.org