I can't say I'm a fan of the idea, but it would be possible. Though for convenience, a bunch of extensions, scripts, and tricks should be setup to make everything easily usable before moving. I've only contributed one or two patches to the Pywikipediabot code, but I'm avid with the MediaWiki coding. If you do chose to switch to this method, I'd be happy to develop many of the extensions which would be plugged into MediaWiki to make it as convenient to use with the code as possible.

Some notes I should make: * A default wiki install will not work out, so whoever is hosting this wiki should allow for extensions and code to be easily changed by one or more people. * A syntax highlighting editor should be setup in the wiki. It is actually possible to setup EditArea using nothing but User or Site js, so it should be even nicer if we enable this using real script tags that don't suffer from bad browser compatibility. * That downloader should not simply download the latest raw pages, it should be able to work in conjunction with revision numbers to allow people to checkout older versions of the code like it is possible to do with SVN. * The downloader should treat redirects as a cue to delete a file unless that redirect leads outside of the area of the wiki the project code is stored in. If the downloader is working in a limited download scpe (ie: the user ran "downloadcommand filename" instead of just "downloadcommand" then the redirect should be used to find out what other file it should be downloading. * Yes the GeSHi extension alone is pretty nice. But I would advocate extending it to automatically highlight every page that ends with .py, this is because we should not be required to add the source tags to every single python file to have it highlighted. I was considering building an extension to do this with other .css and .js pages, but I would be happy to develop an extension which could autosyntaxhighlight pages with any extension you chose. * Pywikipediabot files should be "Wikified". Ya ya... an extremely strange thing to do... But we can't escape the fact that we're in a WikiText enabled environment. Various strange things will happen to the bot files if we do not consider the fact that pages are formatted before they are saved (Substitution of various things). Because of this we should get used to using a breed of Python and WikiText to create the files. * I suggest the use of &templates=expand in the downloader. This will allow for common things done in Pywikipediabot code to be turned into templates and included into the pages. We already half to escape some templates because we cannot prevent modification of {{subst: without escaping it. So why not just escape all templates when we use them in code. In short get accustomed to using #<nowiki> ...code... #</nowiki> When you are working on Pywikipediabot code which uses the {{}} in templates. * WikiText does strange things when dealing with spaces... One space at the start of a line will enable a pre type area and it'll be pulled out of the code... This means that if for some reason a python page isn't in a pre or source the code that starts with a space will be in a pre, but the other code won't, and things will start to look even stranger. I would advocate the use of tabs instead of spaces. Most text editors handle tabs better than spaces. I know a number which support the tab to indent multiple lines, and shift+tab to unindent a section. If I remember correctly EditArea supported these commands to. And on a number of editors enabling "covert tabs to spaces" makes some pretty funky things happen when editing. The EditArea could also easily be told to convert 4 tabs to spaces, it has a built in regex replacer. just hit CTRL+R, or we could create an easy plugin to add a button to do so. Or, a plugin could automatically convert the 4 spaces you type at the start of a line into a tab automatically (Just make sure that you have selected the edit area not the page when you do that.) Or, we could even easily tell MediaWiki to convert the spaces at the start of the line into tabs on save. * Current Pywikipediabot code is restricted to editing by only a limit of people. For doing this in a wiki, we'll need some sort of namespace, or pattern extension which will * The downloader should not depend on Pywikipediabot code. It should be able to function on it's own without any external python scripts. (Someone may be running a broken Pywikipediabot and need to run the downloader to grab the release with the bugfix in it, plus we want to let people download just the downloader instead of downloading the entire archive) * Downloading the archive should always include the downloader. * The downloader should not be automatically downloaded by itself when downloading in case it gets broken. But the downloader should notify the user when a new version has been added. * The &ctype= should be extended to allow application/octet (I believe that was the mime type) so that we can give users a link to directly download one of the scripts instead of telling them to use a Save As. * The newest version of DPL should be installed. Using this we can generate a dynamic list of the Python files. * A special page should be made to list the revisions by revision id in a limited scope displaying what comments were made (namespace/prefix limits). DPL can create a dynamic list, but while it may be able to sort by revision, it will not list double revisions to a file. * Disabling the case sensitivity will allow us to properly name files. But it may cause linking issues if manuals are moved to the wiki. For this reason, I would suggest a name format "Code:Pywikipedia/filename.py" In this way, the Code: namespace will have the restrictions enabled on it. And The first name before the / will be considered much like a repo. So the repo in this case would be Pywikipedia. We can allow other branches and projects by using other repo names. So if someone created a branch of Pywikipediabot code for Wikia they could put code in "Code:Pywikia/filenname.py" and so...

Who do you intend to host this? If you're moving to a technically oriented wiki structure, I don't know how mutable installing a wiki on the Wikimedia servers will be for using custom extensions. If you don't have anyone else I could probably get JaeSharp to host the wiki. We don't have VM's up so I can't give you SSH access yet. But I decided to setup a forge system because I needed a better controlled SVN structure and you could probably make due easily by having the Wiki in SVN and I could put up a simple script or Webmin command to execute svn update on the wiki. I planned a Pywikiaxircbot project awhile back (It's an IRC Bot to control a remote installation of Pywikipediabot... Basically bot control via permissions instead of installation to allow non technically knowledgeable people to run replace or sync bots on their Wikia wiki) so it wouldn't be out of my range. ^_^ plus it would give me an excuse to dish out a heap of interesting extensions.

~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com

Milos Rancic wrote:

As time is passing MW is better and better editor. It is also a very good system for version control...

I was writing everything except programs in my local MW. After I realized that there is syntax highlighting extension (not JS, but, for now good enough inside of preview), I decided to move all of my code to MW, too.

I'll make a script which would be able to download and execute program from MW installation. This means that I would be able to keep everything inside of MW and to execute it from any place on the system.

If we think further, we may realize that it is completely possible to keep the code inside of MW and to generate nightly snapshots using python script dedicated for that.

Personally, I think that MW is much better system for version control because it is highly human readable and writable. And some group should start to use it... And pywikipedia developers are the perfect group to start to do that :)

The only problem which I heard in relation of MW usage instead of CVS/SVN is that programmers like to update their repositories with one command. Solutions for that may be:

• Generating CVS/SVN updates from MW using some script.
• Extending programs which use CVS/SVN for MW usage.

I didn't hear any other reason why not to use MW as version control system. So, if there are some other problems, I would like to know for them. AFAIK, everything which CVS/SVN may -- MW may it; as well as MW with some scripts may some thing much better.

So, what do you think?

---

Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/pywikipedia-l