-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all!
I get following error while using git:
> error: Your local changes to the following files would be
overwritten > by merge:
> maintenance/make_i18n_dict.py Please, commit your changes or stash
> them before you can merge. Aborting
I never did one single change to this file, so whats the point here?
@xqt: might that be the kind of stashing issues you encounter too?
Greetings
DrTrigon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlI9UrsACgkQAXWvBxzBrDAGDQCdHfZULyktjM3+tforfUs1/kwd
EnkAn1Jh4niupzUL2UOD9E6rCw9PKcQV
=lPpj
-----END PGP SIGNATURE-----
I just moved all of page and subpages of Manual:Pywikipediabot to
Manual:Pywikibot in mediawiki.org
Please help us on updating documentations
Cheers
--
Amir
Hey,
While looking at the source of the pywikipediabot in the past, I noticed
that it contained a bunch of Wikibase specific code (sometimes even
Wikidata specific). The code I saw often did a poor job at separating
different concerns, and did some weird things to represent parts of the
Wikibase data model.
I figured it'd be a lot nicer if there was a clean and correct
implementation of the Wikibase data model that can then be used by
pywikipediabot, and other Python projects that need to interact with a
Wikibase instance. I went ahead and created what is essentially my first
ever Python project [0] to do exactly this. (This is far from fully
implemented, and only linked to here to give you an idea of what I am
talking about.)
Since I'm not following pywikipediabot development closely, I'm not aware
of how much interest there is for having such a component. I'm also not
sure on what exactly would need to be implemented to serve the needs to the
pywikipediabot codebase, or on how to proceed to then starting with the
refactorings required to make use of it.
What is essentially needed for this to go forward is a pywikipediabot
developer that takes charge of this project. If that happens I'll happily
make the contributions required to ensure the data model implementation is
done both correctly and cleanly.
[0] https://github.com/JeroenDeDauw/WikibaseDataModelPython
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all!
We have again the discussion about BS (beautifulsoup) and externals.
Just a thought about that; might it be possible that we have a
philosophy mismatch between win (xqt, ...) and linux (me, ...) users?
Might it be possible that win users want to have "everything" included
whereas linux useres are used to have independent packages with
dependencies between them?
If this is the problem, what about having averything included e.g. in
the nightly release? I do have no idea about how nightly works and
whether this is already the case? This release would then be >100MB but
as used from python "with batteries included".
Thanks for your replies! Greetings
DrTrigon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlIwpaUACgkQAXWvBxzBrDB0GwCgnwhzDYoSqOtpZWJdGW7MbjHM
DgsAn1IRphbyjhmD46b5sCTF/UIxKwE2
=yu3C
-----END PGP SIGNATURE-----
> On Mon, Sep 9, 2013 at 2:40 PM, <info(a)gno.de> wrote:
>
> > Hi Amir,
> >
> > I am against this breaking change and I do not see the advantage for
> that.
>
> The big advantage is after using this version there is no need to download
> and install more after downloading PWB compat and this is really helpful
> for people who are using servers in order to run bots (because they doesn't
> have admin rights to install beautifulsoup) and more than 100 projects are
> using this way so why not us?
I agree with having BeautifulSoup as part of the framework (which was it til few months ago). It is a main part of the compat branch and no script will run without it. As suggested (see below) I would prefer the alternate bs3 i.e. BeautifulSoup.py eighter in topmost folder (as it was previously) or in the external folder. I do not see any advantage for bs4 and your renaming.
>
>
> > I guess we will never have a compat release for python 3+.
>
> This is in my TODO list but not a big priority because nobody like python 3
I do not dislike py3+ but I do not like a lot of pywikbot branches because it is hard to work to keep them on the same level. core branch was started 6 years ago and it needs this time to be accepted by more and more bot owners. If we try to merge to py3+ we should do it with core imho
>
>
> > Therefore we could have the BeautifulSoup.py in the topmost folder (as we
> > had before some patching changes) or in the externals folder (as we have
> it
> > while downloaded by its first use whicht is made by
> externals.__init__.py).
> >
> > We just need to set an amend for it, not a big deal. I'll do very soon
Be aware there could be other scripts from bot owners using beautifulsoup directliy and not via pywikibot/wikipedia module.
>
>
Greetings
xqt
FYI:
I submitted https://gerrit.wikimedia.org/r/#/c/83643/ to core which will
fix this.
item.getID() (and property, claim) will now return the uppercase id.
-- Legoktm
---------- Forwarded message ----------
From: Daniel Kinzler <daniel.kinzler(a)wikimedia.de>
Date: Tue, Sep 10, 2013 at 3:11 AM
Subject: [Wikidata-tech] BREAKING CHANGE: Wikidata API changing top
upper-case IDs.
To: "Discussion list for the Wikidata project." <
wikidata-l(a)lists.wikimedia.org>, wikidata-tech <
wikidata-tech(a)lists.wikimedia.org>,
mediawiki-api-announce(a)lists.wikimedia.org
Hi all.
With today's deployment, the Wikibase API modules used on wikidata.org will
change from using lower-case IDs (q12345) to upper-case IDs (Q12345). This
is
done for consistency with the way IDs are shown in the UI and used in URLs.
The API will continue to accept entity IDs in lower-case as well as
upper-case.
Any bot or other client that has no property or item IDs hardcoded or
configured
in lower case should be fine.
If however your code looks for some specific item or property in the output
returned from the API, and it's using a lower-case ID to do so, it may now
fail
to match the respective ID.
There is potential for similar problems with Lua code, depending on how the
data
structure is processed by Lua. We are working to minimize the impact there.
Sorry for the short notice.
Please test your code against test.wikidata.org and let us know if you find
any
issues.
Thanks,
Daniel
PS: issue report on bugzilla:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53894
_______________________________________________
Wikidata-tech mailing list
Wikidata-tech(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
> I use this command and change every usage of BS (case in point
> https://gerrit.wikimedia.org/r/#/c/83372/4/reflinks.py)
> grep "(?:from|import) BeautifulSoup" ~/compat-git/*.py
> you can do it and see
>
As I said on my last reply there could be other scripts from bot owners which use bs directly and not via wikipedia/pywikibot module. I suggest waiting for additional opinions before merging to the repo.
Greetings
xqt