Wikidata-tech June 2015

wikidata-tech@lists.wikimedia.org

8 participants
6 discussions

Need to support PHP 5.3?
by Jeroen De Dauw 29 Jun '15

29 Jun '15

Hey, I'm wondering if we still need to support PHP 5.3. http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html I'd rather bump the minimum version up to PHP 5.5, and know people have been talking about doing the same for MediaWiki itself. My question is if this can already be done without making Wikibase undeployable on WMF servers. Is everything running HHVM yet, or is there some stuff relevant to Wikibase that still runs an unsupported version of PHP? Cheers -- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3

4 8

Dump requirements
by Daniel Kinzler 29 Jun '15

29 Jun '15

There's an ongoing discussion in ops about improving the dump process, see https://phabricator.wikimedia.org/T88728 https://phabricator.wikimedia.org/T93396 https://phabricator.wikimedia.org/T17017 https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Backlog/Improv… I would like to join in and add our requirements and thoughts to the list, and would like some input on that. So far I have: Make it easier to register a new type of dump via a config change. A dump should define: * a script(s) to run * output file(s) * the dump schedule * a short name * brief description (wikitext or HTML? translatable?) * required input files (maybe) Make clear timelines of consistent dumps. * drop the misleading "one dir with one timestamp for all dumps" appraoch * have one timeline per dump instead * for dumps that are guaranteed to be consistent (one generated from the other), generate a timeline of directories with symlinks to the actual files. Make dumps discoverable: * There should be a machine readable overview of which dumps exist in which versions for each project. * This overview should be a JSON document (may even be static) * Perhaps we also want a DCAT-AP description of our dumps Promote stable URLs: * The latest dump of any type should be available under a stable, predictable URL. * TBD: "latest" URL could point to a symlink, get rewritten to the actual file, or trigger an HTTP redirect. Thoughts? Comments? Additions? -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

1 0

pywikibot: how to add claims to a property page?
by Marco Fossati 17 Jun '15

17 Jun '15

Hi everyone, I am the maintainer of the DBpedia mapper bot [1]. Currently, I'm trying to add claims to property pages. There seems to be no implementation in pywikibot to add a claim to a property page. For an 'ItemPage' [2], I proceed as per the following (dummy) example: site = pywikibot.Site("wikidata", "wikidata") repo = site.data_repository() item = pywikibot.ItemPage(repo, item_id) claim = pywikibot.Claim(repo, 'P1709') claim.setTarget('http://dbpedia.org/ontology/Espresso') item.addClaim(claim) As property pages should be instances of 'PropertyPage' [3], I would expect an 'addClaim' method implemented there, but that's not the case. I tried with the 'DataSite.addClaim' method [4] (used by ItemPage [5] BTW), but it cries at [6] since the PropertyPage object has no 'claims' attribute. The edit from the Wikidata Web UI is indeed possible, so my question is: how can I add a claim to a property page with pywikibot? Thanks for your time, cheers! [1] https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/DBpedia… [2] http://pywikibot.readthedocs.org/en/latest/pywikibot/#pywikibot.__init__.It… [3] http://pywikibot.readthedocs.org/en/latest/pywikibot/#pywikibot.__init__.Pr… [4] http://pywikibot.readthedocs.org/en/latest/pywikibot/#pywikibot.site.DataSi… [5] https://github.com/wikimedia/pywikibot-core/blob/master/pywikibot/page.py#L… [6] https://github.com/wikimedia/pywikibot-core/blob/master/pywikibot/site.py#L… -- Marco Fossati http://about.me/marco.fossati Twitter: @hjfocs Skype: hell_j

1 0

Change: including entrypoint now required for Wikibase
by Jan Zerebecki 17 Jun '15

17 Jun '15

Your Wikibase installation will now require you to include its entrypoint. (No change needed for production.) If you didn't already have something like this in your LocalSettings.php you now need to: require_once "$IP/extensions/Wikibase/Wikibase.php"; Or alternatively: require_once "$IP/extensions/Wikibase/repo/Wikibase.php"; require_once "$IP/extensions/Wikibase/client/Wikibase.php"; Change that caused this: https://gerrit.wikimedia.org/r/#/c/217947/ There might be future changes in this area, for switching to https://www.mediawiki.org/wiki/Manual:Extension_registration but those should hopefully be backwards compatible to the above. -- Regards, Jan Zerebecki

3 2

Tiny possibly breaking API change (wbeditentity & wbgetclaims)
by Addshore 15 Jun '15

15 Jun '15

Please see the lower portion of the commit message of this change which has now been merged: https://gerrit.wikimedia.org/r/#/c/217885 I don't image this will break anything really, unless scripts are written expecting 'claim' as the type here. Addshore

1 0

Composer.lock
by Matthew Flaschen 04 Jun '15

04 Jun '15

I could use some feedback related to https://gerrit.wikimedia.org/r/#/c/215815/1 ("Use composer install, not composer update"). Composer strongly recommends committing both composer.json and composer.lock to the repository (https://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file). This means the user can install the exact dependencies tested by the last developer who updated composer.lock (the goal is that you will only commit composer.lock if the dependency set works). Can you comment at https://gerrit.wikimedia.org/r/#/c/215815/1 on why Wikibase does not commit it? Thanks, Matt Flaschen

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Wikidata-tech June 2015