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@arctus.nl An: Pywikipedia discussion list pywikipedia-l@lists.wikimedia.org, yuriastrakhan@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l