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(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/pywikipedia-l