For me splitting the repository depends on how to proceed the checkout of all new
repositories and externals. At the moment I have 4 repositories for developing (2 trunk 2
rewrite) and two (1/1) for committing approved changes and two (1/1) on a different
machine for running the bot in autonomous mode. I do not like virual environment for
developing, i didn't get it working in past.
I would prefer splitting the framework trunk and rewrite and perhaps in next future a new
py3.0 framework based on the rewrite branch. Next I would split i18n from these framework
forks as they must be the same; now trunk use it as external from rewrite. In a same way
the family files could be separated when the framework is able to handle remaining
different setting (e.g. namespaces, ssl etc.)
Also I have the idea to split scripts from the framework and enable running the same
script with different frameworks (look at noreferences.py: only the imports are
different). This means most bots must become a library and all interfaces must be the
same, independent from py release and api/screen scrapping modules.
Happy new year
xqt
----- Original Nachricht ----
Von: Merlijn van Deen <valhallasw(a)arctus.nl>
An: Pywikipedia discussion list <pywikipedia-l(a)lists.wikimedia.org>rg>,
yuriastrakhan(a)gmail.com
Datum: 27.12.2012 20:09
Betreff: Re: [Pywikipedia-l] git migration: repository structure
On IRC, I had a quick chat with Yuri on this issue. A
few pointers
from the discussion - (I hope I worded your points correctly, Yuri -
if not, please correct me!)
On 27 December 2012 16:00, Merlijn van Deen <valhallasw(a)arctus.nl> wrote:
In our repository, we have the following
projects:
- pywikiparser
- threadedhttp
- pywikipedia
pywikiparser should certainly be split, but threadedhttp might warrant
some discussion:
and I think we should also split off the third
party libraries - and
maybe remove them altogether. It might make sense to package them in
the nightlies, though.
Basically, the question boils down to whether we want a 'pure'
repository (which is harder to install, especially on windows), or a
repository where third-party libraries (which sort-of includes
threadedhttp - it doesn't need pywikipedia to function) are included.
I'm inclined to say we should have an easy-to install bundle for
windows users and developers (e.g. using PyInstaller), and have
something virtualenv- and pip-based (or just installed packages) for
linux users, but Yuri is a proponent of bundling everything in the
repository.
- split off family files
- split off userinterfaces (?)
Yuri thinks, and I am inclined to agree, that we should not split
these - they really are part of the core framework, and cannot easily
be used outside of it.
One last thing we could not really agree on is how big the 'user, not
developer'-market is: how many people are using the bots, but are not
programmers (and thus do not write/improve the bots)?
Merlijn
_______________________________________________
Pywikipedia-l mailing list
Pywikipedia-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l